SSL Labs: Stricter Security Requirements for 2014

Ivan Ristic
Ivan Ristic
- 2 min read

Last updated on: September 6, 2020

Today, we’re releasing a new version of SSL Rating Guide as well as a new version of SSL Test to go with it. Because the SSL/TLS and PKI ecosystem continues to move at a fast pace, we have to periodically evaluate our rating criteria to keep up.

We have made the following changes:

  • Support for TLS 1.2 is now required to get an A. If this protocol version is not supported, the grade is capped at B. Given that, according to SSL Pulse, TLS 1.2 is supported by only about 20% servers, we expect this change to affect a large number of assessments.
  • Keys below 2048 bits are now considered weak, with the grade capped at B.
  • Keys below 1024 bits are now considered insecure, and given an F.
  • MD5 certificate signatures are now considered insecure, and given an F.
  • We introduce two new grades, A+ and A-, to allow for finer grading. This change allows us to reduce the grade slightly, when we don’t want to reduce it to a B, but we still want to show a difference. More interestingly, we can now reward exceptional configurations.
  • We also introduce a concept of warnings; a server with good configuration, but with one ore more warnings, is given a reduced grade A-.
  • Servers that do not support Forward Secrecy with our reference browsers are given a warning.
  • Servers that do not support secure renegotiation are given a warning.
  • Servers that use RC4 with TLS 1.1 or TLS 1.2 protocols are given a warning. This approach allows those who are still concerned about BEAST to use RC4 with TLS 1.0 and earlier protocols (supported by older clients), but we want them to use better ciphers with protocols that are not vulnerable to BEAST. Almost all modern clients now support TLS 1.2.
  • Servers with good configuration, no warnings, and good support for HTTP Strict Transport Security (long max-age is required), are given an A+.

I am very happy that our rating approach now takes into account some very important features, such as TLS 1.2, Forward Secrecy, and HSTS. Frankly, these changes have been overdue. We originally meant to have all of the above in a major update to the rating guide, but we ran out of time, and decided to implement many of the ideas in a patch release.

Show Comments (13)

Comments

Your email address will not be published. Required fields are marked *

  1. Hi Ivan,

    We are using Apache 2.2.23 with the below configurations which is now geting 'B' grade, I have tried upgrading the apache to the latest version 2.2.26 but still I am seeing it getting the garde 'B' can you please suggest what other configurations are needed to get 'A' grade.

    Current configurations  which is showing as 'B' grade.

    SSLProtocol -all +SSLv3 +TLSv1

    SSLHonorCipherOrder On

    SSLCipherSuite RC4-SHA:HIGH:!ADH

    Can you please suggest on how to get my web site 'A' grade.

    Thanks

    Suresh

    Reply to knsuresh@steelwedge.com

    1. Suresh,

      Please ask your question in the discussion area: https://community.qualys.com/community/ssllabs

      Also, from your question it’s not clear why exactly you’re getting the B. The report will enumerate all the problems at the top, just beneath the grade.

      You’ll find some good advice here:

      https://community.qualys.com/blogs/securitylabs/2013/08/05/configuring-apache-nginx-and-openssl-for-forward-secrecy

      But with Apache 2.2.x you won’t be able to have Forward Secrecy (the best grade will be A-).

      Thanks,

      Ivan

      Reply to Ivan

    2. @"Suresh K" it is simple, your configuration does not support TLSv1.2 and so breaks the rule: Support for TLS 1.2 is now required to get an A. See details in article above.

      There are five protocols in Apache httpd SSLProtocol setting: SSLv2, SSLv3, TLSv1, TLSv1.1 and TLSv1.2, by setting: SSLProtocol -all +SSLv3 +TLSv1 you have disabled the most secure protocols TLSv1.1 and TLSv1.2. Why did you do this?

      I suggest to set the:

      SSLProtocol all -SSLv2

      or with the exact same meaning:

      SSLProtocol -SSLv2 +SSLv3 +TLSv1 +TLSv1.1 +TLSv1.2

      and if this is the only problem you got grade capped to B, you gona have A- grade.

      Maybe you can also consider to upgrade to Apache 2.4.x. Is is very small difference in settings between Apache 2.2.x and 2.4.x. I needed to change only two lines of setting in my config file and everything is up and running in new 2.4.x server with many new features (like Forward Secrecy support) etc. See upgrade info: https://httpd.apache.org/docs/trunk/upgrading.html especially Access Control section.

      Reply to j-mailor

  2. What do you consider a long max-age for HTTP Strict Transport Security? 

    It would be nice if the SSL report linked to a page showing what you consider a long max-age to be, instead of just saying NOT LONG.

    Thanks,

    Tim

    Reply to Tim

  3. These are all very good changes. We still have some work to do in terms of TLS 1.2. Running on FreeBSD it is not easy to upgrade OpenSSL without creating a messy environment, but we should have that sorted within the next few weeks now that FreeBSD 10 has been released and its openssl version has finally been bumped to something which supports the good stuff we want.

    One question though. This result:

    https://www.ssllabs.com/ssltest/analyze.html?d=webcollect.org.uk

    is slightly surprising, as it shows:

    Strict Transport Security (HSTS)            No

    But that is definitely enabled. This is the header:

    Strict-Transport-Securitymax-age=31536000

    We have had it working and showing "Yes" before on a FreeBSD machine with more up-to-date openssl. HSTS has no interdependency with TLS1.2 etc, so why not show it as HSTS=Yes?

    Thanks

    Reply to oschonrock

    1. HSTS does not show because SSL Labs does not see it. It made one request, got a redirection, and HSTS was not present. (I checked.)

      If you look at the bottom of the page, you’ll find that there was a redirection to (plaintext) http://webcollect.org.uk from an SSL request. This in itself is wrong. Someone going directly to your web site (before seeing HSTS) would be exposed to a HTTPS stripping attack.

      So if you make sure that all SSL requests have the HSTS header, it will show up. The only catch might be that you have to take hostname variants (with www and without) into account.

      Reply to Ivan

  4. Thanks Ivan

    You’re right. I was getting caught out by the "www. killer" redirect handler. This is central on the server for all domains, so I missed it and I was not testing www.* whereas ssl labs apparently was despite me feeding it a non-www domain (I guess it does both?).

    Our central www killer was getting 2 things wrong:

    a) not retaining SSL during the www killer redirect

    b) not serving HSTS header during that redirect

    It now does, plus a few more improvements like redirecting http://www.domain  to https://domain in one step, rather than 2.

    Thanks again, perhaps this google bait helps someone.

    Reply to oschonrock

  6. Ivan,

           The SHA-2 certificate chain is failing in cases where a cross signed chain exists, and the extra SHA1 intermediate is offered.  Many CA’s cross sign to support legacy clients that may not yet trust the new root.  In this case, our choices are:
            1. Include SHA-1 intermediate in bundle, even though it’s not used in establishing the chain we get knocked down.
            2. Don’t include the SHA-1 intermediate.  Legacy clients will resolve it, but have to chase authority information in order to do so.

             My opinion is the test should pass if the actual chain used to verify the cert is SHA-2.  Removing the SHA-1 cross signed intermediate benefits the test score at the expense of performance/risk of AIA chasing.

    Reply to brihow