TLS Version Intolerance Continues To Pose A Problem
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.
5 Ways to Determine if a Website is Fake, Fraudulent, or a Scam – 2018in Hashing Out Cyber Security
How to Fix ‘ERR_SSL_PROTOCOL_ERROR’ on Google Chromein Everything Encryption
Re-Hashed: How to Fix SSL Connection Errors on Android Phonesin Everything Encryption
Cloud Security: 5 Serious Emerging Cloud Computing Threats to Avoidin ssl certificates
This is what happens when your SSL certificate expiresin Everything Encryption
Re-Hashed: Troubleshoot Firefox’s “Performing TLS Handshake” Messagein Hashing Out Cyber Security
Report it Right: AMCA got hacked – Not Quest and LabCorpin Hashing Out Cyber Security
Re-Hashed: How to clear HSTS settings in Chrome and Firefoxin Everything Encryption
Re-Hashed: The Difference Between SHA-1, SHA-2 and SHA-256 Hash Algorithmsin Everything Encryption
The Difference Between Root Certificates and Intermediate Certificatesin Everything Encryption
The difference between Encryption, Hashing and Saltingin Everything Encryption
Re-Hashed: How To Disable Firefox Insecure Password Warningsin Hashing Out Cyber Security
Cipher Suites: Ciphers, Algorithms and Negotiating Security Settingsin Everything Encryption
The Ultimate Hacker Movies List for December 2020in Hashing Out Cyber Security Monthly Digest
Anatomy of a Scam: Work from home for Amazonin Hashing Out Cyber Security
The Top 9 Cyber Security Threats That Will Ruin Your Dayin Hashing Out Cyber Security
How strong is 256-bit Encryption?in Everything Encryption
Re-Hashed: How to Trust Manually Installed Root Certificates in iOS 10.3in Everything Encryption
How to View SSL Certificate Details in Chrome 56in Industry Lowdown
PayPal Phishing Certificates Far More Prevalent Than Previously Thoughtin Industry Lowdown