SSL Labs 1.17: RC4, Obsolete Crypto, and Logjam
Last updated on: September 6, 2020
Yesterday we released SSL Labs 1.17.10, whose main goal was to introduce grading adjustments we had talked about a month ago. We delivered the planned changes as well as a few additional tweaks. Our release coincided with an announcement of a new attack against TLS, called Logjam, and we had some time to work on that, too.
RC4
As discussed last month, starting with this version we are increasing our penalty for using RC4 with modern TLS versions, namely TLS 1.1 and better. Sites that do that are now capped at C. Sites that use RC4 only with older clients will be capped at B. Sites that do not use RC4 will get an A, assuming absence of other problems.
No TLS 1.2 Support
It is important for servers to support modern protocols in order to take advantage of the best security features present in modern clients. To emphasise this, sites that don’t support TLS 1.2 are now capped at C (was B previously). This most recent TLS version is the only version that supports authenticated suites (AEAD), which are currently the only properly secure type encryption in TLS. It came out in 2008 and there was a long gap before it was implemented by browsers in 2013. Today, seven years later since the RFC, there should be no excuse for not supporting it.
Logjam
Logjam, the new attack on weak Diffie-Hellman (DH) parameters is yet another reminder that supporting obsolete cryptography is never a good idea. Even though TLS provides a negotiation mechanism that should in theory enable modern clients to communicate using only strong security, in practice there are ways to abuse either the clients or the protocol and perform downgrade attacks.
Diffie-Hellman key exchange strength is a relatively obscure aspect of TLS protocol configuration. Until recently, most web servers didn’t even have an ability to tune this setting, and some servers don’t even today. That wouldn’t be a problem, except that most servers default to insecure values. SSL Labs started highlighting servers with weak DH parameters some years ago in an effort to raise awareness of this issue.
Logjam affects only incorrectly configured SSL/TLS servers. Those who have followed best practices (e.g., SSL/TLS Deployment Best Practices from SSL Labs) aren’t using any of the vulnerable cryptography and need not make any changes to mitigate LogJam. In addition, for performance reasons, well-tuned sites prefer key exchanges based on Elliptic Curve cryptography, avoiding problems with DH altogether. In SSL Labs, servers vulnerable to the LogJam attacks are graded as F; no changes were made specifically for this attack.
That said, we did extend our SSL/TLS Client Test to detect when user agents accept Diffie-Hellman key exchange that has only 512 bits of security.
Weak DH Parameters
Even though for most sites there isn’t an immediate vulnerability if they’re using 1024-bit DH parameters (state attacks are not part of most sites' threat model), such parameters are weak and should be discouraged. We have been warning about weak DH parameters for a long time; now, with the announcement of Logjam, we feel that it’s a good time to move one step further. As of yesterday, sites that continue to use weak DH parameters are capped at B.
SSL labs still shows FS for DHE suites, which is incorrect regardless of the length. will this be fixed?
lily wilson I suppose we will have to re-evaluate the FS status of DHE suites. I think they’re still potentially better than RSA suites, because obtaining a server’s key is much easier than breaking its DH parameters. Especially if you’re rotating your DH parameters frequently. But I suppose no one would actually do that.
DHE is still FH. The issue is only that 1024-bit DH is vulnerable to sieving precomputation attacks that can violate forward secrecy. Larger DH moduli are currently safe and can be considered sufficient to provide FS.
A client side vulnerability detection for " Logjam" will be updated automatically to the scanners in the next hours. For the server side vulnerability detection, which covers more the preventive side and affected configurations, we are currently working on a series of QID’s scheduled to be released early next week.