SSL Labs: Stricter security requirements for 2014

http://blog.ivanristic.com/2014/01/ssl-labs-stricter-security-requirements-for-2014.html

by ivanr • 13 years ago

103 54 13 years ago

blog.ivanristic.com

2bluesc• 13 years ago

The test tool is pretty handy too. If only I could convince some of my service providers to care...

rickette• 13 years ago

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.

zobzu• 13 years ago

amazing i don't know but its useful, it helps raising awareness a lot.

briansmith• 13 years ago

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?

ivanr10• 13 years ago

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.

wommpomm• 13 years ago

i agree, i've only just got to the point of needing to look at this sort of site and the SSL labs is an amazing site. Thank you

aroch3• 13 years ago

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?

ivanr10• 13 years ago

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.

aroch3• 13 years ago

Thanks, that's what I thought.

riteshpatel• 13 years ago

A+ without any changes, whoop :)

https://www.ssllabs.com/ssltest/analyze.html?d=theticketfair...

gog• 13 years ago

Can you share the nginx config?

knite• 13 years ago

Yes, please!

RKearney2• 13 years ago

Not OP, but here's the relevant portion of my Nginx config that scores an A+

https://gist.github.com/ryankearney/8552425

aroch3• 13 years ago

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.

http://idzr.org/r0v7

Also, my nginx.conf includes

        add_header Strict-Transport-Security "max-age=31536000; includeSubDomains";

shebson• 13 years ago

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.

rbritton• 13 years ago

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.

daeken• 13 years ago

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!

adam-f• 13 years ago

Sadly, the blog isn't available over https.

tptacek• 13 years ago

I really wish it wasn't possible to get an A- with RC4 enabled.

scott_karana2• 13 years ago

Agreed. I feel like everyone will just keep limping along with OpenSSL 0.9.8...

yuhong• 13 years ago

I think this is the same test that once made it impossible to get an A if RC4 is not on top of the ciphersuite list.

ivanr10• 13 years ago

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...

ivanr10• 13 years ago

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.

jvehent• 13 years ago

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!

blueskin_3• 13 years ago

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.

blueskin_3• 13 years ago

Yep. It used to limit to a B with RC4 enabled.

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.

scott_karana2• 13 years ago

For someone without the time to compile OpenSSL and nginx/apache, what is a recommended Linux distro with support for TLS 1.2 and PFS?

I'm normally a Debian Stable and CentOS6 guy, but both fall flat here, last I checked.

agwa3• 13 years ago

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.

ivanr10• 13 years ago

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.

makomk• 13 years ago

The nginx package in Wheezy supports both TLSv1.2 and ECDHE as well as AES-GCM, I'm using them with it at the moment.

pixl97• 13 years ago

CentOS6 OpenSSL supports TLS1.2 and PFS

https://www.ssllabs.com/ssltest/viewClient.html?name=OpenSSL...

CentOS 6.5 comes with nginx 1.0.15 which by the documentation supports TLS1.2

agwa3• 13 years ago

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.

ceejayoz2• 13 years ago

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.

spamizbad• 13 years ago

AFIAK it's not possible to get an A+ with Amazon's ELB, but it's sometimes hard to parse Amazon's abridged cipher names.

It also doesn't help that Amazon gives you a TON of junk ciphers (like the anon ones) but is missing some stronger ones.

conorgil145• 13 years ago

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.

stud: https://github.com/bumptech/stud

ceejayoz2• 13 years ago

Yeah, no A+ possible, but the closest to it would be nice.

taway20122• 13 years ago

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.

Identical SSL configurations otherwise.

Is this expected? Or am I doing something wrong?

legutierr• 13 years ago

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

3. Generate a single SAN certificate that references both domains (http://en.wikipedia.org/wiki/SubjectAltName) Not all certificate issuers can generate a SAN certificate.

taway20122• 13 years ago

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.

Now I get A+ on SSL Labs for both sites.

dave1010uk• 13 years ago

Can anyone share the bits of an Apache config required to get an A+? Even better would be an Ansible / Puppet / Chef cookbook.

mdewinter• 13 years ago

Here is a fairly extensive guide for Apache: https://raymii.org/s/tutorials/Strong_SSL_Security_On_Apache... - Also one for nginx:https://raymii.org/s/tutorials/Strong_SSL_Security_On_nginx.... - This will get you an A+.

mike-cardwell• 13 years ago

The only "fail" for grepular.com is:

  IE 6 / XP - No FS - No SNI - Protocol or cipher suite mismatch

This is because I disabled SSLv3 which means people using IE6 on WinXP simply can't access the site. I see this as more of a win than a fail.

dspillett• 13 years ago

IIRC IE6 on XP can support TLSv1.0 but it was disabled by default until IE7.

dobbsbob• 13 years ago

Tested some email providers

Neomailbox A

Countermail.com B

Cryptoheaven.com F "world's safest email" lol

Riseup.net the service political activists rely on only uses TLS1.0/SSL3

hsivonen• 13 years ago

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.

ivanr10• 13 years ago

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.

SSL Labs: Stricter security requirements for 2014

Related Stories