What’s New SSL Labs 1.26.5 (13 Jan 2017)
Last updated on: October 21, 2021
Today saw another SSL Labs release, which brings several new features and includes one fix. In this blog post I will discuss what the new features are and why they’re interesting. As always, you’ll find the (recent) history of SSL Labs releases in the change log.
Improved cipher suite testing: faster and better!
The cipher suite testing has been optimised to produce better results faster—the best of both world. We’ve written about this before so you can find the details in this blog post. In a nutshell, cipher suites are now reported on per-protocol basis, and even with SNI disabled. This thorough approach gives a complete view of server’s configuration.
Detection of CAA policies
Certification Authority Authorization (CAA), defined in RFC 6844, is a new standard that allows domain name owners to control which CAs are allowed to issue certificates for their properties. SSL Labs now detects when CAA is defined on a hostname.
Detection of ECDHE server parameter reuse
During the ephemeral Diffie-Hellman key exchange—both the standard (DHE) and elliptic curve (ECDHE) variants— client and server are expected to both generate one-time (hence the word ephemeral) secrets that are used in the process. Because secret generation takes some time, some servers reuse secrets. In the worst case, the reuse is indefinite (in practice until process restart); in some cases, there’s a time limit.
This type of flaw first came into the spotlight with Logjam because it made attacks much easier (and, in fact, possible). Further, a recent paper titled Measuring the Security Harm of TLS Crypto Shortcuts indicates a widespread reuse of DHE and ECDHE parameters. Reuse of ECDHE server parameters is not as dangerous (or immediately exploitable), but it’s still a problem. SSL Labs has long had detection for reused DHE server parameters; this version adds the same test for ECDHE.
Detection of supported named curves and preferences
Until recently, most servers supported a limited set of named curves for the ECDHE key exchange, because only secp256r1 and secp384r1 were useful in practice; browsers didn’t support much else. Since RFC 7748 added support for two new modern curves, x25519 and x448, we are seeing more and more servers adding support for them. Thus, it makes sense to have a separate test that inspects all supported named curves and the order in which they are negotiated.
Continued improvements to the next-gen API (v3)
As SSL Labs continues to evolve, we continue to extend the API. The approach we’re taking is to keep version 2 of the API stable, but to improve (wit breaking changes) version 3. In this SSL Labs release, API v3 simulation fields have been extended to carry additional information about the negotiated key exchange and the server’s certificate. (Earlier changes were adding support for multiple certificates as well as a full dump of all observed HTTP transactions.) You can find the complete API v3 documentation.
Client Test added support for GREASE suites
TLS, one of the most widely encryption protocols and certainly the most diverse one, has had a long-standing problem with intolerance problems of one sort or another. The basic issue is that servers are written to expect a certain type of traffic and panic if they see anything they consider to be unusual.
In the end, the community decided that intolerance problems can’t be prevented, but they need to be dealt with early on. The key to doing that is detection. To that end, David Benjamin proposed GREASE, that a standard way for TLS clients to continuously offer unusual protocol elements, effectively forcing the broken serves to be fixed. The SSL Labs Client Test now detects GREASE elements for what they are.
Client Test added support for TLS 1.3 suites
TLS 1.3, which is almost around the corner, introduces new cipher suites. Don’t worry, the number of suites is not going to continue to increase. TLS 1.3 deprecated all earlier cipher suites, and introduces only 5 new ones. The SSL Labs Client Test now detects the TLS 1.3 suites correctly.
The new SSL Labs test also detects support for DNS CAA records on the domain being tested.
You’re right! I’ve now updated the release notes and this blog post with a mention of CAA detection. Thanks!
Another question:
When SSL Labs lists named curves, does it take into consideration whether any such curves are cryptographically “weak” and adjust the grade accordingly?
No, not at this time. Technically, it should be done, but in practice I haven’t seen any servers that support weak curves. We’ll monitor the results for a period of time and then react accordingly.
Will TLS 1.3 support be added to SSLLabs server scanning any time soon? TLS 1.3 servers have been around for a while (in CloudFlare’s case, several months) and at the moment all I can see is that they screw up the TLS 1.2 results a bit.