(No Ratings Yet)

Loading...

• Facebook
• Twitter
• LinkedIn
• Mail

August 5, 2016 Comments closed

TLS Version Intolerance Continues To Pose A Problem

in Everything Encryption

New Data From SSL Pulse Shows TLS Version Intolerance Continues to Cause Issues

TLS version intolerance, also referred to as protocol intolerance, is a pervasive bug in web server software. When present, it can prevent an SSL/TLS connection from being established.

The SSL/TLS protocol has had five major revisions over its 20+ year life. Despite all the improvements and lessons that have been learned through those iterations, the underlying problem causing version intolerance was not fixed until recently. The next version, TLS 1.3, will resolve the majority of version intolerance problems. However, software that poorly conforms to the SSL/TLS specification will continue to have this bug, which will still present a significant hurdle for the industry.

What is Version Intolerance?

TLS version intolerance is a problem that occurs during the SSL Handshake, the process through which an SSL/TLS connection is made.

To start a handshake, the client “advertises” its TLS capabilities in a message known as ClientHello. This involves the client telling the server all its technical capabilities, including the newest protocol version it supports. For instance, a modern client like Google Chrome would say ‘I support TLS 1.2.’

The server would then compare those capabilities to its own, choose the strongest methods available, and send its choices back so that both parties know how they will be making the connection – this message is the ServerHello. If the server did not support the same protocol version, it would send back the next newest version it does support. For example, it’s common that servers are further behind the curve than clients, so the server may say ‘I support TLS 1.1. If you do too, let’s use that.’

Having agreed upon TLS 1.1, the rest of the handshake occurs and a connection is made. That’s how everything should work.

When there is TLS version intolerance, things don’t go quite so smoothly. In our above example, the problem would occur when the server receives the ClientHello. If the server does not recognize the advertised TLS version, it simply stops the connection there. This is not what the SSL/TLS specification calls for, but a large amount of software implements it improperly and small mistakes are abundant.

Usually, servers experience version intolerance when a new protocol is released. For example, the software code may only be written to understand what versions existed at the time. So when a new version is presented, it has no instructions on how to react.

Why is TLS Version Intolerance a problem now?

The answer is TLS 1.3. Now, it’s not that there is anything specifically wrong with TLS 1.3. Version intolerance is an issue anytime a new protocol version is released. TLS 1.3 just happens to be the next version of the TLS protocol, due to be completed soon (internet standards work takes a long time. It is hard to say exactly when TLS 1.3 will be finalized – but it’s something that the internet has begun preparing for).

New TLS protocol versions are a big deal – the current version, TLS 1.2 – was released back in 2008. Needless to say, there have since been major advances in protocol design, cryptography, and security, which will be incorporated into 1.3.

But new data published by Qualys suggests that deployment of TLS 1.3 may be problematic because of servers with version intolerance. Their SSL Pulse project scans the SSL/TLS configuration of 150,000 of the world’s most popular websites each month.

SSL Pulse found that, as of last month (July 2016), 3.2% of servers have problems properly responding to SSL handshakes which offer TLS 1.3. Ivan Ristić, who works on the SSL Pulse project, said “[3.2%] doesn’t sound like much, but it’s a huge problem for browsers because it translates to thousands of sites, some very popular.”

Fixing version intolerance problems either requires that servers fix their software through an update, or the problem can be fixed on the client side. Web browsers implement a mechanism known as voluntary protocol downgrade. It is essentially an intelligent auto-retry, where the browser continues to initiate new handshakes, incrementally advertising lower protocol versions until the connection is successful. Without this mechanism, trying a new connection would just lead to the same failure over and over – because each time the client would advertise the problematic version.

Unfortunately, voluntary protocol downgrade has downsides. Negotiating a connection takes longer when it is used, because the browser is actually making multiple attempts one after another. These downgrades also pose a security risk.  Version intolerance is a problem that really needs to be fixed on the server-side, instead of having browsers compensate for it.

Ivan Ristić is the author of Bulletproof SSL and TLS, and is one of the world’s leading experts on SSL/TLS. He hared his thoughts on protocol design and version intolerance on the Qualys blog.

Future versions of SSL Pulse will continue to publically track version intolerance.[1]

[1] https://twitter.com/BhushanLokhande/status/761007853503180800

• #SSL
• #TLS
• #TLS Version Intolerance