I wish that too. I don't like the idea of having a demonstratively weak cipher in my SSL configuration, either. On the other hand, RC4 remains the only reliable way to defend against BEAST. Modern browsers might have addressed this issue, but there remain large numbers of users who are using older (unpatched) browsers and have (unpatched) Java enabled too. Plus, RC4 weaknesses are (as far as we know) not practical to exploit.
I am not afraid about BEAST, but I felt it would be wrong to penalize those who have legitimate reasons to be worried. In the end, it's all about context.
That said, perhaps the penalty for using RC4 with TLS 1.1 and better (which are not vulnerable to BEAST) should have been harsher. I'll consider it for a future update.
I agree. Unfortunately, there is currently no way to configure different ciphersuites for different versions of TLS. With issues like BEAST, it would be highly beneficial if Apache, Nginx & others would supports ciphers preferences per TLS versions.
That still wouldn't help old clients. For them, only one solution: upgrade!
Yes, that would be nice. I've heard that PolarSSL has per-protocol suite selection. It's really something the underlying SSL library needs to support.
With OpenSSL, the best we can do right now is prioritize suites so that SHA2 ones are on top. By doing that, you know that TLS 1.2 capable clients are going to use good suites. The rest will fall back to whatever is below.
>Modern browsers might have addressed this issue, but there remain large numbers of users who are using older (unpatched) browsers and have (unpatched) Java enabled too.
At some point, the world will have to tell them "you're on your own" like it finally did with IE6. Perhaps give them helpful informative messages to upgrade - I bet if Facebook and Twitter redirected old browsers to such a page, their market share would shrink to negligible levels overnight.
Is it possible to give an 'upgrade' message to old browsers in this case though? If they fail the SSL handshake then they'll see a browser error before it loads anything from your site.
I agree with the principal of pushing people towards upgrading, but it's harder if you can't show them a helpful message to explain things.
It's possible in some cases. For example, most sites continue to support SSL v3, even though only very old clients do not support TLS v1. So now would be a good time to tell those clients that they need to upgrade. If we don't do it now, SSL v3 might become too insecure for error messages. (Like, for example, SSL v2 is today.)
With regards to BEAST, the problem is that a server has no way of telling if a client implements the mitigation technique. The only 100% safe assumption you can make is that the client negotiating TLS 1.0 is vulnerable.
The server can make an educated guess based on the useragent. If someone is spoofing UA to an older browser, all bets are off, but then they presumably know what they are doing.
I use CipherFox (https://addons.mozilla.org/en-US/firefox/addon/cipherfox/) to disable RC4, then only enable it specifically when it is needed as far too many servers not only support it, but attempt to use it when a client still supports non-broken/backdoored algorithms.
Not only is RC4 weak, but it was designed by an RSA Security employee. RSA have proven they can not be trusted, and I think are now on the slow slide into decline and death. Contracts will sustain them for a few years, but they certainly aren't getting any more of those now.
Like it or not, sometimes it's necessary to choose the less of two evils. There was a time when BEAST was the best known attack against SSL, RC4 was not thought to be as weak as it is today, and RC4 was the only way to mitigate BEAST server-side. Eventually, even Safari/OSX implemented the 1/n-1 split defense against BEAST, at which point we stopped requiring server-side mitigation for it.
EDIT: actually, SSL Labs stopped requiring server-side BEAST mitigation a month or so before Apple finally handled BEAST in OSX Mavericks. It happened only after I had been satisfied that BEAST exploitation was not very likely. You can find more information here: http://blog.ivanristic.com/2013/09/is-beast-still-a-threat.h...
Ivan, it would be helpful to define what a "long max-age" is, exactly. In order to qualify for Firefox's HSTS preload list, max-age=10886400 or higher is required. Are you using the same boundary, or a different one?
It's 180 days (or 15,552,000 seconds) at the moment. I have it documented in the rating guide, but I should probably mention it somewhere in the report. I am not sure that's long enough, by the way. There are some important sites I visit only once in a long while, and I would prefer to be protected on every visit.
For your needs (HSTS preloading), a shorter value is probably fine.
I'm stuck at B because Fedora's Apache and OpenSSL packages have not yet been updated to fix the items necessary to go beyond that. It's not a high risk enough site to warrant compiling and maintaining the build myself.
> It's not a high risk enough site to warrant compiling and maintaining the build myself.
Doing so would -- unless you're extraordinarily fastidious -- more than likely open you to more risk than the existing issues. Keeping up with security patches is more important, and your package manager is almost definitely better at it than you are. So keep doing what you're doing -- you're good!
I'd love to see a canonical "pick these suites" article for Amazon's Elastic Load Balancers. I've managed an A- but it'd be nice to know which of the 50ish ciphers shown in ELB config I should be picking.
I just went through a similar process with ELB. Unfortunately, ELB does not support ECDHE so if you want to use perfect forward secrecy, DHE is your only available option there and it is much slower than ECDHE. I switched to using stud to resolve SSL so that we could enable ECDHE.
Woo, I get an A+. Do you have any comments on using 'includeSubDomains' with HTST? I've had some people tell me not to use it and other to use it. Are there any major security implications?
Ideally, you should always use "includeSubdomains" with HSTS. This will provide robust security for the main hostname as well as all subdomains. The issue here is that (without "includeSubdomains") a man in the middle attacker can create arbitrary subdomains and use them inject cookies into your application. In some cases, even leakage might occur.
The drawback of "includeSubdomains", of course, is that you will have to deploy all subdomains over SSL.
SSL labs is an amazing site. I use it frequently to alert co-workers about potential weaknesses in our SSL setup. Having a SSL labs testreport makes it easier to grasp for everyone involved.
An interesting effect of this is that everyone using ssl provided by CloudFlare's Pro tier now gets dropped to an A- because they use RC4 with TLS 1.1.
Thanks for the test (very useful!) and for the update.
A couple of comments:
"Servers that do not support Forward Secrecy with our reference browsers are given a warning."
Why aren't such servers capped to a non-A rating?
Also, the current scoring scheme that puts Cipher Strength among the bars at the top but doesn't put Forward Secrery there. Is there a reason to believe that it's more worthwhile to highligh symmetric cipher key length than to highlight Forward Secrecy, including the DH group size?
Considering that the security of AES256 might be closer to AES128 per https://www.schneier.com/blog/archives/2009/07/new_attack_on... and running more rounds might give more opportunity for timing attacks in case a round isn't constant-time, it seems weird to me to highlight the lack of AES256 more than DH group size. Likewise, it seems weird to highlight the difference between AES128 and AES256 more than the difference between RC4 and AES.
I guess that some decisions are easier to make than others. It's quite clear, for example, that protocols before TLS 1.2 are inadequate. Forward Secrecy, on the other hand, is supremely important for some sites (e.g., Google) and not at all important for others (e.g., SSL Labs).
Also relevant is that these new rules are added on top of the 2009 rating guide, which does not offer an adequate framework for them. Just as an illustration, there is currently no meaning behind the A-F grades. A is good, and F is bad, clearly, but we don't know what the grades in between mean.
Same response to your ciphers question. I can't stretch the current approach to go handle those small differences. The calculations made some sense at the time, but they no longer work for everything we want to take into account.
I currently working a new version of the rating guide--from scratch--and it's going to solve all those problems, and a few more.
You have robust Forward Secrecy, so nothing to worry about. (I use the term "robust" to mean that you support both ECDHE and DHE suites, providing Forward Security to a wide range of clients)
Before, there used to be a note at the top when a site supported Forward Secrecy, but the score was not affected. With this update, there's a slight penalty if Forward Secrecy is not supported. The errors and warnings now appear only when they affect the score.
Unfortunately RedHat (and by extension, CentOS) [edit: prior to RHEL/CentOS 6.5] strips elliptic curve crypto out of OpenSSL, so the list of ciphers you linked to is not accurate. For PFS on CentOS you're stuck with the slower discrete log Diffie Hellman.
Edited to add: my information is out of date! See ivanr's reply.
It used to. As far as I know RHEL 6.5 was the first to enable Elliptic Curve cryptography by default. Fedora 18 and later were updated to support it, too. For more details, see here: https://bugzilla.redhat.com/show_bug.cgi?id=319901
Debian Stable (Wheezy)'s OpenSSL has everything you need: TLSv1.2, elliptic curve crypto. However, its Apache doesn't support elliptic curve crypto so you'll have to use the slower discrete log Diffie Hellman to get PFS with Apache. I'm not sure about the version of nginx in Wheezy.
If you're stuck with Apache 2.2.x (and thus no support for Elliptic Curve crypto), perhaps you should give TLS Interposer a try: https://netfuture.ch/tools/tls-interposer/ It adds ECDHE support without having to upgrade to Apache 2.4.x.
I host two sites on the same IP. The first site declared in my nginx conf file got A+. The second one got A with a note that it doesn't work in browsers without SNI.
If you are using the same IP to host two domains, each with a separate certificate, then only one certificate can be default and associated with that IP when SNI is not enabled. NGINX is probably choosing one of your two domains to be "default" (if you haven't set it up that way explicitly). What happens when you hit the server without any domain (i.e. via IP address in the browser)? Is the site you see the one that got the A+?
SNI is what allows you to use two different certificates (associated with two different domain names) with the same IP address. Your choices seem to be:
1. Rely on SNI, which doesn't work with IE on WinXP, or on 2.x Android;
2. Give your server two public IPs, with each pointing to a different domain; OR
Thanks for the response. I get the A+ site when I directly visit via IP.
I went through the delta between the reports with a fine-toothed comb and discovered that SNI wasn't the problem. It was a biggie: looks like HSTS wasn't enabled for visits to the static part of the site (like the homepage).
It seems like Nginx is doing something counter-intuitive. I've set HSTS at the server level using the 'add_header' directive.
I've set 'max-age=0, must-revalidate' at the location level using add_header for the static parts of my site. I expected Nginx to add both add_headers, but it only seems to do the "deepest" set of add_headers it finds.
Duplicating the 'add_header' directive at the location level (resulting in two add_header directives) results in HSTS being sent for the static parts also.
Also not the OP, but this is my conf and it got an A+ with no modifications. Redirects http://www and http:// to https://example.com (also strips www from https://www.), supports sdpy where appropriate, and does OCSP stapling.
- You don't need the builtin session cache. According to the Nginx documentation, it's more efficient to rely only on shared memory alone.
- You should use a longer session duration. Five minutes is too short. Use at least one hour there.
- For performance reasons, you might want to enable OCSP stapling.
- SSL Labs does not currently penalize Diffie-Hellman parameters of 1024 bits (the Nginx default), but it's something you should generally look to improve. It's easy with the ssl_dhparam directive. (Some libraries, for example Java 6 and 7, does not support DH params over 1024 bits, though. So take that into consideration.)
Thanks for all these suggestions. I was able to implement all of them except for oscp stapling due to our version of nginx not supporting it. Once that gets upgraded that can be implemented too.
