SSL Labs End of Year 2014 Updates

Ivan Ristic

Last updated on: September 6, 2020

From the SSL/TLS perspective, 2014 was quite an eventful year. The best way to describe what we at SSL Labs did is we kept running to stay in the same place. What I mean by this is that we spent a lot of time reacting to high profile vulnerabilities: Heartbleed, the ChangeCipherSpec protocol issue in OpenSSL, POODLE (against SSL 3 in October and against TLS in December), and others. Ultimately, this has been a very successful year for us, with millions of assessments carried out.

We have just deployed what is principally our last update for 2014, bringing several improvements and refinements:

  • We made a series of improvements to our grading criteria, to keep up with recent discoveries and continue to nudge site operators to improve their configurations:
    • Servers that support SSL 3 are now capped at B (C if vulnerable to POODLE).
    • Grade F given to servers that support only SSL 3.
    • Servers that support RC4 are capped at B.
    • Incomplete certificate chains capped at B.
    • A+ servers are now expected to support TLS_FALLBACK_SCSV and have a SHA2 certificate chain.
  • The Client Capabilities test has been extended to test client support for all protocol versions, from the first SSL 2 until the most recent TLS 1.2. There have been many improvements to handle various edge cases.
  • Our SSL/TLS Deployment Best Practices guide has been fully updated.
  • SSL Labs APIs and our open source client tool for automated bulk testing have become available for early access. We are very excited about our making our APIs publicly available and hope that this will make it easier for system administrators to keep an eye on their systems.
  • There have been many small improvements throughout, thanks for the attention to detail of the members of our growing SSL Labs community.

According to SSL Pulse, before these changes we had about 24% secure servers. Now, the latest results (not yet released, but will be soon) show that number drop down to 11%. This shows that others, too, have to “run” in the same way that we do.

Naturally, we have many plans for 2015, but we’ll talk about them in a couple of weeks. In the meantime, I hope that you will enjoy the SSL Labs updates.

Show Comments (2)

Leave a Reply to Janusz Dziemidowicz Cancel reply

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

  1. This does not look quite right to me.

    Qualys SSL Labs – Projects / SSL Server Test / identity.virginmedia.com gets a B but it is presently both TLS 1.2 intolerant and requires an RC4-based cipher suite for TLS.

    In my opinion, there is a difference between merely offering RC4 and any common, modern TLS clients negotiating an RC4-based cipher suite. I would cap to C where this occurs with TLS in any version. With draft-ietf-tls-prohibiting-rc4-01 upcoming, I definitely feel that this is justified.

    (XP’s SCHANNEL doesn’t classify as being a modern client and, while it does have 3DES available, there are performance justifications in certain use cases for instead retaining RC4 at the tail end of the preferred cipher suite ordering where no modern client will negotiate it and the present B is reasonable.)

    The only situation where RC4 being preferred should not cap to C is where it is with SSLv3 only as it mitigates POODLE.

    TLS 1.2 or 1.1 intolerance should cap to a C.

    TLS 1.3 intolerance should, for now, cap to a B.

    We need to get to the position where version fallback does not take place in browsers.

    (I should state that I feel the scoring isn’t weighting correctly as it doesn’t really motivate many people to fix anything. Commonly I get the response that a B isn’t that bad. We should, I think, see use of the D grade, with everything being shifted around: Anything that presently gets an A- should become a B, B to C and C to D. What I’ve said above should be read in the context of the present weighting, not what I hope to see.)

  2. It is nice to see public key pinning test. However, I’ve noticed one thing that is missing from the PKP test which might be very useful for server operators. The PKP draft requires that there is at least one pin that does NOT refer to an SPKI in the certificate chain (see section 4.3). This is so called backup pin in case of a key compromise. The browsers are required to ignore the pinning if there is no backup pin (section 2.5). The test currently does not check this and displays a nice green indicator even if only one pin is present.