edit: Or is this about the fact that it supports forward secrecy?
This link has a nice rundown of why RC4 is no longer recommended for SSL/TLS: http://blog.cryptographyengineering.com/2013/03/attack-of-we...
"According to AlFardan, Bernstein, Paterson, Poettering and Schuldt (a team from Royal Holloway, Eindhoven and UIC) the RC4 ciphersuite used in SSL/TLS is broken. If you choose to use it -- as do a ridiculous number of major sites, including Google -- then it may be possible for a dedicated attacker to recover your authentication cookies. The current attack is just on the edge of feasibility, and could probably be improved for specific applications."
The BEAST penalty applies even if the preferred AES-CBC ciphers are defined by TLSv1.2 and thus shouldn't be vulnerable to BEAST.
But don't blame us, that's just the current situation with SSL/TLS. We're only reporting it. BTW, we used to show scores in the result, but too many people were trying to game the system (rather than be reasonable). As a result, we're showing only the grades now. In the future, the numerical scoring will be probably removed completely (switching to rule-based scoring).
As for BEAST, our test tests SSL 3.0 and TLS 1.0 specifically, but not TLS 1.1+. So, the way to go with BEAST is to force RC4 with TLS 1.0 and earlier, some CBC suite with TLS 1.1, and GCM suites with TLS 1.2.
> So, the way to go with BEAST is to force RC4 with TLS
> 1.0 and earlier, some CBC suite with TLS 1.1, and GCM
> suites with TLS 1.2.
I'd love to get rid of the BEAST penalty, but there are no good (high-volume) stats on what percentage of "all" users is vulnerable to the BEAST attack. Because Apple is not yet deploying 1/n-1 in their browsers, the vulnerable BEAST percentage is still quite high. On SSL Labs, about 15%.
Given that attacks against RC4 are not very practical (yet), one possible direction is to focus on supporting TLS 1.2 (without RC4, obviously), at which point both RC4 and BEAST attacks will become irrelevant.
Please don't. The more attention is paid to it, the more ammo I have in pressuring the manufacturers of certain embedded systems I'm stuck dealing with to upgrade their ancient browser codebases.
Is it possible to configure nginx like this? From what I can tell, there is no way to select a cipher based on the protocol.
This is from an example that's not related to PFS, so some tuning may be needed. The example is from my (free) OpenSSL Cookbook, which you can get from here:
You are required to register in order to get the book (because the book is not just the PDF). If you don't want to receive any email from me, after you log in, go to the Settings section and unsubscribe from the marketing list.
These are my test results: https://www.ssllabs.com/ssltest/analyze.html?d=forkly.com
Thanks for the help :)
I call this a feature and part of the sad state of the web. In other words i think that is a point they would like to illustrate. I dont think a 100% score should be possible if it isnt technically correct. Poor compatibility on the browser end isnt really their problem and certinly shouldn't limit scoring.
Adam Langley suggested on HN a few months ago that he was more comfortable with RC4 than with AES-CBC, which TLS unfortunately (due to its '90s heritage) specified in a MAC-then-encrypt construction that leaks timing, but the RC4 attack is scarily simple. Both attacks are extremely noisy, though; with what we understand about the flaws now, you'd surely notice if either attack was being directed at you.
RC4 is broken and the bias attack is very bad, but the attack requires a lot more connections.
The next step for SSL Labs is to start to reward sites when these additional features are deployed.
Unfortunately Firefox doesn't yet have TLS 1.1 enabled (apparently you can manually enable it in about:config in recent versions), but Chromium does.
TLS 1.2 would also give them GCM, but AFAICT the only browser that supports that on Linux is Konqueror.
You can test with a pair of terminals before you go bouncing your server (via ):
openssl s_server -accept 8888 -cert mywebsite.com.pem -pass stdin -cipher ECDHE-RSA-RC4-SHA
<hit enter a few times>
openssl s_client -connect 127.0.0.1:8888 -cipher ECDHE-RSA-RC4-SHA
I don't know what the proper way to get rid of RC4 is.
Chrome says, for the blog mentioned in your profile:
"The connection is encrypted using AES_256_CBC, with SHA1 for message authentication and ECDHE_RSA as the key exchange mechanism."
"ECDHE" means elliptic curve Diffie-Hellman exchange. This means your server, whatever it is, is configured to support perfect forward secrecy. If you're running your own server, you're probably using some recent distribution or Apache release that defaults to enabling ECDHE. Otherwise, your host may have done such configuration themselves.
A bit ironic:
 For the curious, have a look at https://github.com/ssllabs/sslhaf The 0.1.x branch is the stable one; master is moving from an Apache module toward a portable library.
I'm curious about this. Could someone please comment on "the way in which they are typically handled makes them less secure in practice" concern?
Then, you are supposed to rotate your keys when someone leaves, or if there is a compromise. Revoking a shared private key is nearly impossible if it is used in multiple systems. People get really afraid of breaking stuff, and if they do, it takes them ages to fix everything.
I have a lot of users with older browsers so that's really important, not sure if that matters.