SecureState Blog

Read SecureState's award winning blog.

The current state of SSL and how little it has changed in recent years

More of the Same

In 2010 I wrote a small series of blogs (A New HopeThe SSL Strikes BackThe Return of the SSLi and Web Application Security) regarding certain vulnerabilities in many of the SSL implementations that I have found while performing vulnerability assessments. Since this time I have not written much about the topic, so I thought it was time to write an update regarding the current state of websites that are using SSL/TLS to protect their web applications. Sadly, the current state of SSL/TLS is pretty pathetic. As of March 19, 2013 the SSL Pulse Project reported that many of the most popular sites on the Internet are still struggling with correctly implementing SSL!

One of the low points of these statistics shows that of the sites surveyed, approximately 28% were using SSLv2, and 34% were using weak encryption ciphers! Perhaps this would be an appropriate time to mention that SSLv2 was depreciated all the way back in 1996.

SSL Pulse Infographic

 

CRIMES of a BEAST

In addition to SSLv2 and Weak Encryption algorithms, approximately 66% of the web servers SSL Pulse reviewed were vulnerable to the BEAST attack. The BEAST attack is a protocol vulnerability in TLS 1.0 and SSLv3 that an attacker may be able to exploit in order to gain access to a user’s session cookie. This would allow an attacker to use the session cookie to impersonate a user who has connected to a secure server. Unfortunately, this vulnerability could not be addressed through a patch, but required changes to the TLS protocol itself. The vulnerability was addressed in TLS 1.1, but most browsers and servers do not support the newer versions of TLS. For example, SSL Pulse identified that only about 10% of the servers surveyed support TLSv1.1 and 13% support TLSv1.2. The BEAST can be mitigated by removing support for block-based ciphers such as 3DES or AES and using RC4 instead. A second attack that targets the way SSL/TLS is used with sites that support compression (such as TLS Compression and SPDY) is the CRIME attack. According to SSL Pulse about 30% of sites support TLS Compression and only 2.5% support the SPDY Protocol.  It should be noted that in order to pull off the CRIME and/or BEAST attack, many specific conditions must be met. Although these attacks are hypothetically possible, they require the attacker to do some work in order to pull it off.

Authentication Weaknesses

Even if an organization implements SSL perfectly, and has taken steps to mitigate the BEAST and CRIME attacks (along with similar attacks), it is fallacious to believe that they are truly exempt from falling victim to an attack that targets SSL/TLS authentication. In recent years the authentication mechanisms SSL/TLS were built upon has shown weaknesses that shake the very foundations of the trust model that we have come to rely upon. For example, in 2008 researchers were able to generate a rogue Certification Authority certificate based on weaknesses with the MD5 Hashing algorithm; in March of 2011 a Comodo affiliate RA issued fraudulent certificates for 7 domains; in August of 2011 TURKTRUST issued two intermediate certificates (one of which was active until 2013); and in 2012 Trustwave announced that it had issued a root certificate as part of a DLP solution. This list is by no means comprehensive, but provides a sampling of the problems that the authentication model of SSL/TLS faces. At this point it should be obvious that the authentication framework the Internet is built upon is far from reliable. The Electronic Frontier Foundations’ SSL Observatory project reported that there are around 650 organizations that act as certificate authorities. This means that if any one of these 650 CAs is compromised, the trust model of the entire SSL/TLS authentication infrastructure is impacted! This seems like a very flimsy foundation! I was hoping that the Perspectives Project, or Moxie Marlinspike’s Convergence Project (which builds upon the Perspectives Project) would help to eliminate most of the SSL/TLS problems related to the authentication framework, but it does not seem like these projects have been embraced by most of the organizations that can implement widespread change (Google, Microsoft, Apple, etc.).

Conclusion

So in a nutshell, it would appear that many organizations continue to fail to securely implement SSL and SSL’s trust model continues to be a single point of failure. This is deeply concerning considering the fact that SSL/TLS continues to serve as the backbone for securing most of the Internet’s most critical web applications (i.e. online banking, online shopping, etc.). It is also ironic that PCI considers SSL/TLS an acceptable means for protecting cardholder data in transit. PCI requires their merchants to comply with specific standards, but who is forcing the certificate authorities to comply with certain security requirements? At this point I think it is safe to say that SSL\TLS is broken and until the companies that own the main browser market share decide to act, I do not have much hope for the future. In the meantime it would be nice to see the Perspectives, Convergence and TACK projects gain a little momentum, and while the SSL Authentication infrastructure is a mess, there is no excuse for the fact that so many organizations have failed to implement these protocols correctly! It’s time that organizations and the industry as a whole start taking security a little more seriously.