A roster of TLS cipher suites weaknesses(googleonlinesecurity.blogspot.com)
googleonlinesecurity.blogspot.com
A roster of TLS cipher suites weaknesses
http://googleonlinesecurity.blogspot.com/2013/11/a-roster-of-tls-cipher-suites-weaknesses.html
3 comments
A fantastic overview of the past few years of exploits against SSL. All I can add is a companion resource you probably already know about: https://www.ssllabs.com/projects/index.html
But even that doesn't give enough practical advice as to which ciphers to pick. This blog post helps, but basically points out that there's no "perfect replacement" for what SSL ciphers people tend to be using today. That said, any attempt to avoid bad ciphers -- usually defaults -- is better than nothing. Be careful: there are even valid SSL choices that don't encrypt your data at all. Do your research when planning SSL and verify your SSL configuration once you've selected server-side preferred options. It really does matter.
http://security.stackexchange.com/ is useful too, though not as fresh as many security blogs might be.
But even that doesn't give enough practical advice as to which ciphers to pick. This blog post helps, but basically points out that there's no "perfect replacement" for what SSL ciphers people tend to be using today. That said, any attempt to avoid bad ciphers -- usually defaults -- is better than nothing. Be careful: there are even valid SSL choices that don't encrypt your data at all. Do your research when planning SSL and verify your SSL configuration once you've selected server-side preferred options. It really does matter.
http://security.stackexchange.com/ is useful too, though not as fresh as many security blogs might be.
For specific advice, here's my blog post with a proposed configuration that will work with any program that relies on OpenSSL:
That's why I keep the SSL/TLS Deployment Best Practices higher level, without specific cipher suite configuration examples:
http://blog.ivanristic.com/2013/08/configuring-apache-nginx-and-openssl-for-forward-secrecy.html
That's why I keep the SSL/TLS Deployment Best Practices higher level, without specific cipher suite configuration examples:
https://www.ssllabs.com/projects/best-practices/In the blog post above you say that IE 8 on XP doesn't support PFS, but this technet document seems to indicate that a few cipher suites with DHE are available on XP:
http://msdn.microsoft.com/en-us/library/windows/desktop/aa38...
Are all of them problematic for other reasons?
Thanks for all your work in this area!
Are all of them problematic for other reasons?
Thanks for all your work in this area!
Yes, they are problematic. Cipher suites are typically tied to a particular key algorithm. Microsoft does support the DHE key exchange, but only in combination with DSA keys (DSS in the cipher suite string). There are a couple of problems with that. First, if you do use DSA keys, you don't get to use any RSA suites[1], which are much better supported. Just as an illustration Chrome supports only one DSA suite. Second, virtually no one uses DSA keys today for SSL. So, all the advice you will find is about RSA keys. Third, and worst, Microsoft does not actually support DSA keys stronger than 1024 bits, and you can't use 1024-bit keys because they're considered too weak.
I am sure there is a reason, but Microsoft never supported the DHE and RSA combination, which was the only way to achieve Forward Secrecy before ECDHE became widely supported.
[1] Actually, some web servers support multiple keys/certificates. With Apache, for example, you could have an SSL site with RSA, DSA, and ECDSA keys if you wanted. I think nginx is adding this capability too. But IIS does not support it.
I am sure there is a reason, but Microsoft never supported the DHE and RSA combination, which was the only way to achieve Forward Secrecy before ECDHE became widely supported.
[1] Actually, some web servers support multiple keys/certificates. With Apache, for example, you could have an SSL site with RSA, DSA, and ECDSA keys if you wanted. I think nginx is adding this capability too. But IIS does not support it.
I really wish SSL Labs would provide a list of ciphers that actually passes their own test 100%. For example in nginx I have TLSv1 TLSv1.1 and TLSv1.2 enabled, with "ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-RC4-SHA:ECDHE-RSA-AES128-SHA:AES128-SHA:RC4-SHA" for the cipher list. SSL Labs says that TLSv1.2 is not supported, and that I should enable forward secrecy recommending that I put ECDHE ciphers at the top of the list. Not being a security expert I have a really hard time deciphering what I am doing wrong with these two simple settings. (nginx version is 1.4.3).
[I am the author of SSL Labs.] I agree with you that SSL Labs currently does not help non-experts very much; the test is still focused on presenting the details, but without guidance. The next version should be very explicit about what should and should not be done.
As for your case, I propose that you follow my advice from the blog post I linked to earlier. It's much easier to do that then to find out exactly why the results are not as you expect.
As for your case, I propose that you follow my advice from the blog post I linked to earlier. It's much easier to do that then to find out exactly why the results are not as you expect.
I will give it a try. BTW, great service. Thank you very much for running it!
I really like Mozilla's recommendations, which are detailed, explicit, and well-justified: https://wiki.mozilla.org/Security/Server_Side_TLS#Recommende...
It's probably not complete fantasy to believe somewhere in the billion dollar funded NSA machine, they have cracked RC4
Despite beast, I've disabled it completely and gone to AES with EC ciphers.
Despite beast, I've disabled it completely and gone to AES with EC ciphers.
Microsoft's regrettable browser-tying/integration strategy has exacerbated web crypto problems. And it doesn't look like Microsoft is going to stop doing it, either--ten years from now we'll be dealing with whatever crypto suites the maximum IE version supports on Windows 7.
I'm picking on Microsoft here, but the same is true for any platform browser. Crypto suites need to be completely modular, enabling backporting to old environments.