> 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.)
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.)
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.
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/m...
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.
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.
First off, let me say thanks for an awesome tool. Just because I disagree with the preference of RC4 over AES-CBC doesn't mean I don't think SSL Labs is incredibly useful (I use it all the time to test TLS configs).
In my opinion, if being vulnerable to BEAST means you aren't 'perfect' and capped at a B, then allowing RC4 should have the same effect, as there are very real attacks against TLS's implementation of RC4 as well.
I look forward to the day when we can shut off TLS 1.0 altogether... We disabled SSLv3 a month ago (once it dropped below 1% of our traffic). Alas, TLS 1.0 is still almost 2/3rds of our traffic. The good news is, with the release of Chrome 29 Stable, we've seen a _huge_ spike in TLS 1.2 traffic.
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.
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.
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
[2]: https://www.ssllabs.com/ssltest/index.html