3 ms·

> Note that ECDH and DH are different authentication mechanisms: these require special certificates and offer no forward-secrecy. I contacted the author about

> Note that ECDH and DH are different authentication mechanisms: these require special certificates and offer no forward-secrecy. I contacted the author about this, but I don't think this is correct. The OpenSSL ciphers documentation[1] says "DH" is simply all suites using Diffie–Hellman, not necessarily authenticated DH, which is "aDH". I actually couldn't check if it does include aDH since `openssl ciphers -v 'aDH'` tells me I don't have any aDH ciphers! Unfortunately there's no documentation to explain the difference between EDH (ephemeral DH?) and DHE. Are they synonyms? I'm assuming DHE is ephemeral since using a string with DHE Will get you Perfect Forward Secrecy "points" on an SSL Labs test[2]. (Run the test! Secure your web servers! You can get at least a B rating easily enough.) [1]: http://www.openssl.org/docs/apps/ciphers.html http://www.openssl.org/docs/apps/ciphers.html [2]: https://www.ssllabs.com/ssltest/index.html https://www.ssllabs.com/ssltest/index.html

xnyhps 13y ago
I clarified that I mean to refer to those with OpenSSL names that start with "ECDH-" and "DH-", which is not the same as what the shorthand "DH" gives you. As far as I can tell, EDH is an older synonym for DHE. I like the ssllabs test and I hope this sort of testing gets more common for TLS usage that isn't HTTPS. However, I think a B is still cause for concern. You can only obtain a B if you have a) SSLv2 enabled (which is broken), b) cipher suites enabled with <128 bit symmetric keys, c) a RSA private key with less than 1024 bits or d) if you don't mitigate BEAST. I think only d) is a valid excuse under some circumstances. On the other hand, a 1024 bit RSA key with SSLv3 and only RC4 will give you an A, but I would not call this very secure anymore.
- aprescott 13y ago
  I indeed managed to get a B without trying to mitigate against BEAST (d). The trouble does seem to be that RC4 isn't vulnerable to BEAST, but it's not desirable because of its other vulnerabilities. Since BEAST was fixed in TLS 1.1, I think you can require 1.1+ and get an A, but the test suggests you might break things for a significant chunk of users. Even if you get a B because you're vulnerable to BEAST, if you prioritise 1.1+ ciphers, you'll still fail to get an A but you'll mitigate against it. It looks like Qualys themselves have a post on this, actually: https://community.qualys.com/blogs/securitylabs/2011/10/17/mitigating-the-beast-attack-on-tls https://community.qualys.com/blogs/securitylabs/2011/10/17/m...
  - JshWright 13y ago
    In my opinion, it's irresponsible of Qualys to put so much emphasis on BEAST. It's been mitigated in every major browser and most other clients. RC4 is not a better alternative (as it shortcomings can't be overcome unilaterally in client implementations), and it's dangerous to give it so much weight in the scoring.
    - harshreality 13y ago
      I'm pretty sure it was securitymetrics that I recall was failing a site for PCI compliance last year due to lack of server-side BEAST mitigation (using ciphersuite order to prefer RC4). I don't think it's only Qualys. I think it's most of the industry.
    - ivanr 13y ago
      First of all, I think it's perfectly reasonable to not get an A if your security is not perfect. Thus, BEAST does not carry "so much weight". For a lot of weight, look at SSL 2 or insecure renegotiation -- if you have those enabled you get an F. I know that everyone assumes the BEAST had been addressed, but that's not actually the case. Safari continues to be vulnerable. BEAST is actually still exploitable (against Safari), because the Java Same-Origin Policy bypass that was used originally still remains (in a slightly different form; they appear to have failed to fix it). But you won't hear about this, because people have moved on to the next exciting thing and no one bothers to check. There is one positive change and that is that the Java plug-in does not appear to have access to httpOnly cookies, making BEAST less interesting. Still, other cookies, HTTP Basic Authentication, and URL-based sessions remain vulnerable. Some might say that supporting TLS 1.1+ deals with the problem. It might, but it might not, because most browsers are susceptible to protocol downgrade attacks. An active MITM might be able to force TLS 1.0 and then exploit BEAST. I have so far determined that all browsers downgrade connections in case of failure. I am soon to test if they have some sort of rollback defense. I am well aware that RC4 is not a good cipher, and it pains me to continue to indirectly encourage people to use it. I am sorry I cannot move at a faster pace, but researching these things takes considerable effort, and thus time. It's actually pretty likely that next week, after I finish with some further tests, SSL Labs will stop penalizing for the BEAST vulnerability. [Note: I am the guy behind SSL Labs.]
- ivanr 13y ago
  Yes, I agree. To get an A these days, a site should at the very least support TLS 1.2, and use a key stronger than 1024 bits. That's where we're heading. P.S. If you have SSL 2 enabled, you'll get an F.
e12e 13y ago
I think that's "ADH", not "aDH": $ openssl ciphers -v aDH Error in cipher list 140473872484008:error:1410D0B9:SSL routines:SSL_CTX_set_cipher_list:no cipher match:ssl_lib.c:1314: $ openssl ciphers -v ADH ADH-AES256-GCM-SHA384 TLSv1.2 Kx=DH Au=None Enc=AESGCM(256) Mac=AEAD ADH-AES256-SHA256 TLSv1.2 Kx=DH Au=None Enc=AES(256) Mac=SHA256 ADH-AES256-SHA SSLv3 Kx=DH Au=None Enc=AES(256) Mac=SHA1 ADH-CAMELLIA256-SHA SSLv3 Kx=DH Au=None Enc=Camellia(256) Mac=SHA1 ADH-DES-CBC3-SHA SSLv3 Kx=DH Au=None Enc=3DES(168) Mac=SHA1 ADH-AES128-GCM-SHA256 TLSv1.2 Kx=DH Au=None Enc=AESGCM(128) Mac=AEAD ADH-AES128-SHA256 TLSv1.2 Kx=DH Au=None Enc=AES(128) Mac=SHA256 ADH-AES128-SHA SSLv3 Kx=DH Au=None Enc=AES(128) Mac=SHA1 ADH-SEED-SHA SSLv3 Kx=DH Au=None Enc=SEED(128) Mac=SHA1 ADH-CAMELLIA128-SHA SSLv3 Kx=DH Au=None Enc=Camellia(128) Mac=SHA1 ADH-RC4-MD5 SSLv3 Kx=DH Au=None Enc=RC4(128) Mac=MD5 ADH-DES-CBC-SHA SSLv3 Kx=DH Au=None Enc=DES(56) Mac=SHA1 EXP-ADH-DES-CBC-SHA SSLv3 Kx=DH(512) Au=None Enc=DES(40) Mac=SHA1 export EXP-ADH-RC4-MD5 SSLv3 Kx=DH(512) Au=None Enc=RC4(40) Mac=MD5 export Also note: $ openssl ciphers -v ADH|wc -l 14 $ openssl ciphers -v DH|wc -l 38
- aprescott 13y ago
  The strings and documentation don't make it too easy to distinguish, but the docs do explicitly distinguish between aDH and ADH. I think "DH" includes any and every cipher that might use DH, but there's a good chance that for a cipher string like TLS_DH_DSS_WITH_AES_256_GCM_SHA384, which uses "DH", it's actually part of the "aDH" umbrella (certificate carries DH keys). (Credit to the original author of the article for spotting that one via RFC5246.)
  - e12e 13y ago
    Yes, you're right - from chiphers(1): aDH cipher suites effectively using DH authentication, i.e. the certificates carry DH keys. Not implemented. ADH anonymous DH cipher suites.
    - 13y ago

xnyhps 13y ago

I clarified that I mean to refer to those with OpenSSL names that start with "ECDH-" and "DH-", which is not the same as what the shorthand "DH" gives you. As far as I can tell, EDH is an older synonym for DHE. I like the ssllabs test and I hope this sort of testing gets more common for TLS usage that isn't HTTPS. However, I think a B is still cause for concern. You can only obtain a B if you have a) SSLv2 enabled (which is broken), b) cipher suites enabled with <128 bit symmetric keys, c) a RSA private key with less than 1024 bits or d) if you don't mitigate BEAST. I think only d) is a valid excuse under some circumstances. On the other hand, a 1024 bit RSA key with SSLv3 and only RC4 will give you an A, but I would not call this very secure anymore.

aprescott 13y ago
I indeed managed to get a B without trying to mitigate against BEAST (d). The trouble does seem to be that RC4 isn't vulnerable to BEAST, but it's not desirable because of its other vulnerabilities. Since BEAST was fixed in TLS 1.1, I think you can require 1.1+ and get an A, but the test suggests you might break things for a significant chunk of users. Even if you get a B because you're vulnerable to BEAST, if you prioritise 1.1+ ciphers, you'll still fail to get an A but you'll mitigate against it. It looks like Qualys themselves have a post on this, actually: https://community.qualys.com/blogs/securitylabs/2011/10/17/mitigating-the-beast-attack-on-tls https://community.qualys.com/blogs/securitylabs/2011/10/17/m...
- JshWright 13y ago
  In my opinion, it's irresponsible of Qualys to put so much emphasis on BEAST. It's been mitigated in every major browser and most other clients. RC4 is not a better alternative (as it shortcomings can't be overcome unilaterally in client implementations), and it's dangerous to give it so much weight in the scoring.
  - harshreality 13y ago
    I'm pretty sure it was securitymetrics that I recall was failing a site for PCI compliance last year due to lack of server-side BEAST mitigation (using ciphersuite order to prefer RC4). I don't think it's only Qualys. I think it's most of the industry.
  - ivanr 13y ago
    First of all, I think it's perfectly reasonable to not get an A if your security is not perfect. Thus, BEAST does not carry "so much weight". For a lot of weight, look at SSL 2 or insecure renegotiation -- if you have those enabled you get an F. I know that everyone assumes the BEAST had been addressed, but that's not actually the case. Safari continues to be vulnerable. BEAST is actually still exploitable (against Safari), because the Java Same-Origin Policy bypass that was used originally still remains (in a slightly different form; they appear to have failed to fix it). But you won't hear about this, because people have moved on to the next exciting thing and no one bothers to check. There is one positive change and that is that the Java plug-in does not appear to have access to httpOnly cookies, making BEAST less interesting. Still, other cookies, HTTP Basic Authentication, and URL-based sessions remain vulnerable. Some might say that supporting TLS 1.1+ deals with the problem. It might, but it might not, because most browsers are susceptible to protocol downgrade attacks. An active MITM might be able to force TLS 1.0 and then exploit BEAST. I have so far determined that all browsers downgrade connections in case of failure. I am soon to test if they have some sort of rollback defense. I am well aware that RC4 is not a good cipher, and it pains me to continue to indirectly encourage people to use it. I am sorry I cannot move at a faster pace, but researching these things takes considerable effort, and thus time. It's actually pretty likely that next week, after I finish with some further tests, SSL Labs will stop penalizing for the BEAST vulnerability. [Note: I am the guy behind SSL Labs.]
ivanr 13y ago
Yes, I agree. To get an A these days, a site should at the very least support TLS 1.2, and use a key stronger than 1024 bits. That's where we're heading. P.S. If you have SSL 2 enabled, you'll get an F.

e12e 13y ago

I think that's "ADH", not "aDH": $ openssl ciphers -v aDH Error in cipher list 140473872484008:error:1410D0B9:SSL routines:SSL_CTX_set_cipher_list:no cipher match:ssl_lib.c:1314: $ openssl ciphers -v ADH ADH-AES256-GCM-SHA384 TLSv1.2 Kx=DH Au=None Enc=AESGCM(256) Mac=AEAD ADH-AES256-SHA256 TLSv1.2 Kx=DH Au=None Enc=AES(256) Mac=SHA256 ADH-AES256-SHA SSLv3 Kx=DH Au=None Enc=AES(256) Mac=SHA1 ADH-CAMELLIA256-SHA SSLv3 Kx=DH Au=None Enc=Camellia(256) Mac=SHA1 ADH-DES-CBC3-SHA SSLv3 Kx=DH Au=None Enc=3DES(168) Mac=SHA1 ADH-AES128-GCM-SHA256 TLSv1.2 Kx=DH Au=None Enc=AESGCM(128) Mac=AEAD ADH-AES128-SHA256 TLSv1.2 Kx=DH Au=None Enc=AES(128) Mac=SHA256 ADH-AES128-SHA SSLv3 Kx=DH Au=None Enc=AES(128) Mac=SHA1 ADH-SEED-SHA SSLv3 Kx=DH Au=None Enc=SEED(128) Mac=SHA1 ADH-CAMELLIA128-SHA SSLv3 Kx=DH Au=None Enc=Camellia(128) Mac=SHA1 ADH-RC4-MD5 SSLv3 Kx=DH Au=None Enc=RC4(128) Mac=MD5 ADH-DES-CBC-SHA SSLv3 Kx=DH Au=None Enc=DES(56) Mac=SHA1 EXP-ADH-DES-CBC-SHA SSLv3 Kx=DH(512) Au=None Enc=DES(40) Mac=SHA1 export EXP-ADH-RC4-MD5 SSLv3 Kx=DH(512) Au=None Enc=RC4(40) Mac=MD5 export Also note: $ openssl ciphers -v ADH|wc -l 14 $ openssl ciphers -v DH|wc -l 38

aprescott 13y ago
The strings and documentation don't make it too easy to distinguish, but the docs do explicitly distinguish between aDH and ADH. I think "DH" includes any and every cipher that might use DH, but there's a good chance that for a cipher string like TLS_DH_DSS_WITH_AES_256_GCM_SHA384, which uses "DH", it's actually part of the "aDH" umbrella (certificate carries DH keys). (Credit to the original author of the article for spotting that one via RFC5246.)
- e12e 13y ago
  Yes, you're right - from chiphers(1): aDH cipher suites effectively using DH authentication, i.e. the certificates carry DH keys. Not implemented. ADH anonymous DH cipher suites.
  - 13y ago