30 ms·

A roster of TLS cipher suites weaknesses

38 points by gits1225 13y ago

lstamour 13y ago
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 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/ http://security.stackexchange.com/ is useful too, though not as fresh as many security blogs might be.
- IgorPartola 13y ago
  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).
  - ivanr 13y ago
    [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.
    - IgorPartola 13y ago
      I will give it a try. BTW, great service. Thank you very much for running it!
- ivanr 13y ago
  For specific advice, here's my blog post with a proposed configuration that will work with any program that relies on OpenSSL: http://blog.ivanristic.com/2013/08/configuring-apache-nginx-and-openssl-for-forward-secrecy.html But I've found in practice that many operate under different circumstances. For example, many hardware devices offer only a limited set of cipher suites. To know how to configure them, you have to understand the advantages and limitations of each. 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/
  - bradleyjg 13y ago
    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/aa380512(v=vs.85).aspx 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!
    - ivanr 13y ago
      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.
- zarvox 13y ago
  I really like Mozilla's recommendations, which are detailed, explicit, and well-justified: https://wiki.mozilla.org/Security/Server_Side_TLS#Recommended_Ciphersuite https://wiki.mozilla.org/Security/Server_Side_TLS#Recommende...
ck2 13y ago
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.
isomorphic 13y ago
The elephant in the room for me is the legion of paying customers running old Microsoft browsers. 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.

38 points by gits1225 13y ago

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 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/ http://security.stackexchange.com/ is useful too, though not as fresh as many security blogs might be.

IgorPartola 13y ago
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).
- ivanr 13y ago
  [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.
  - IgorPartola 13y ago
    I will give it a try. BTW, great service. Thank you very much for running it!
ivanr 13y ago
For specific advice, here's my blog post with a proposed configuration that will work with any program that relies on OpenSSL: http://blog.ivanristic.com/2013/08/configuring-apache-nginx-and-openssl-for-forward-secrecy.html But I've found in practice that many operate under different circumstances. For example, many hardware devices offer only a limited set of cipher suites. To know how to configure them, you have to understand the advantages and limitations of each. 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/
- bradleyjg 13y ago
  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/aa380512(v=vs.85).aspx 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!
  - ivanr 13y ago
    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.
zarvox 13y ago
I really like Mozilla's recommendations, which are detailed, explicit, and well-justified: https://wiki.mozilla.org/Security/Server_Side_TLS#Recommended_Ciphersuite https://wiki.mozilla.org/Security/Server_Side_TLS#Recommende...

ck2 13y ago

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.

isomorphic 13y ago

The elephant in the room for me is the legion of paying customers running old Microsoft browsers. 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.