SSL Labs 1.17: RC4, Obsolete Crypto, and Logjam
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.
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 SupportIt 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, 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 didnt even have an ability to tune this setting, and some servers dont even today. That wouldnt 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) arent 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 ParametersEven though for most sites there isnt an immediate vulnerability if theyre 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 its a good time to move one step further. As of yesterday, sites that continue to use weak DH parameters are capped at B.