https://community.qualys.com/blogs/securitylabs/2015/05/22/ssl-labs-increased-penalty-when-tls-12-is-not-supported
Earlier this week we released SSL Labs 1.17.10, whose main purpose was to increase the penalty when RC4 is used with modern protocols (i.e., TLS 1.1 and TLS 1.2). We had announced this change some time ago, and then put in place on May 20. The same release introduced another change, which was to increase the penalty for servers that don't support TLS 1.2 from B to C. And it seems that this second change is being somewhat controversial, with many asking us to better explain why we did that.
Although what initially prompted us to think about changing the grading for not supporting TLS 1.2 was grade harmonisation (ensuring that a wide range of servers all get grades that make sense -- in other words, to have better-configured servers have better grades), that doesn't change the fact that the reality is that TLS 1.0 is an obsolete security protocol. TLS 1.0 came out in 1999, followed by TLS 1.1 in 2003 and TLS 1.2 in 2008. These new protocol versions were released for a reason -- to address security issues with earlier protocol versions. But, despite being obsolete, TLS 1.0 continues to be the best supported protocol version on many servers. It's not very bad, mind you -- we know from SSL Pulse that about 60% of servers already support TLS 1.2. Client-side, the situation is probably better, because modern browsers have supported TLS 1.2 since 2013. You could say that, overall server configuration is the weaker link.
In that light, we feel that the increase of the penalty for the lack of TLS 1.2 is the natural next step in the deprecation of TLS 1.0. In fact, SSL Labs is probably late in doing that. Just last month, the PCI Security Council deprecated SSL v3 and TLS 1.0 for commercial transactions. No new systems are allowed to use TLS 1.0 for credit card processing and existing systems must immediately begin to transition to better protocols. In comparison, the SSL Labs change of grading is only a mild nudge in the right direction. And, while some people are not happy that we're pushing for TLS 1.2, others are complaining that we're not doing enough. For example, the Chrome browser has been warning about lack of TLS 1.2 and authenticated (GCM) suites for some time now. Clearly, it's difficult to make everyone happy.
The bottom line is that TLS 1.0 is insecure and we must migrate away from it. In 2011, there came the BEAST attack, and, in 2013, the Lucky 13 attack. TLS 1.0 remains vulnerable to this problems, but TLS 1.2 (with authenticated suites) isn't. These attacks are serious and some organisations continue to use RC4 in combination with TLS 1.0 just to be sure that they are mitigated. We understand that many organisations face significant challenges adding support TLS 1.2, but that is unavoidable. In computer technology, and in security in particular, it is often necessary to keep running just to stay in place.
We did get one thing wrong, however -- we didn't communicate our grading changes in advance. It was not our intention to surprise anyone. In fact, we'd prefer much more if changes were smoother. To that end, in the future we'll be announcing all grading changes with at least one month notice, and hopefully more for some more significant changes.