You Can Now Help Identify Middleboxes Holding Back TLS 1.3 Adoption
TLS 1.3 promises great improvements for the encrypted Web, both in terms of security and performance. However, its adoption has been held back for the past year by SSL/TLS proxies and other load balancing and traffic monitoring middleboxes that break connections.
Browser vendors have held back adding TLS 1.3 by default because tests showed that the error rates for establishing TLS connections grew unacceptably high when this version was enabled. The results were somewhat unexpected because the TLS protocol was built to be agile.
The problem turned out to be non-standard TLS implementations used in intermediary systems—middleboxes—that broke the protocol’s agility due to certain design decisions. The issue has even received a name: protocol ossification.
This happens when certain elements of a protocol that are intended to be flexible remain unchanged for a very long time, leading certain developers to treat them as constants in their implementations. Then, when those elements are later changed, like with TLS 1.3, things break down.
TLS 1.3 is a major overhaul of the protocol that secures the Web, but the changes it introduces, while significant, shouldn’t have in theory affected backward compatibility. Yet in practice they did, and to fix that, the protocol designers have been forced to resort to tricks.
For example, TLS 1.3 now lies about its own version in the client hello message, essentially masquerading as TLS 1.2, to avoid connection failures. The true version of the client is exposed through a protocol extension that only TLS 1.3-capable servers will understand.
But this wasn’t enough because the removal of certain features in TLS 1.3 that existed in previous versions of the protocol also caused connection failures. It turned out that the developers of many middleboxes made the presence of certain TLS fields like ChangeCipherSpec, session_id and compression a requirement, even though the older protocol specification doesn’t say connections should be refused if those fields are missing.
“It would be disingenuous to put all of the blame for this on the specific implementers of these middleboxes,” said Nick Sullivan, the head of cryptography at Cloudflare, in a blog post. “Yes, they created faulty implementations of TLS, but another way to think about it is that the original design of TLS lent itself to this type of failure. Implementers implement to the reality of the protocol, not the intention of the protocol’s designer or the text of the specification. In complex ecosystems with multiple implementers, unused joints rust shut.”
The answer to this problem? Adding back certain unneeded features to TLS 1.3. Browser vendors, large Internet companies like Facebook and Google and the Internet engineering community spent the last year running tests and collecting information about TLS connection failures in order to figure out ways of tweaking TLS 1.3 in order to fix compatibility with old and poorly implemented middleboxes.
Draft 22 of the TLS 1.3 specification that was published at the end of November contains many of these “fixes,” but it will take a while until browser vendors implement the draft and start doing tests. In the meantime, Cloudflare is calling on the community to help.
The company, which has supported TLS 1.3 on its servers for over a year now, has built a simple website that enables users to test if TLS 1.3 works from their vantage points. The test uses a JavaScript-based TLS 1.3 library to establish a connection through Flash. As a result, the website requires Flash Player to be installed.
“We connect to a remote server using TLS 1.2 and TLS 1.3 and compare the results,” Sullivan said. “If there is a mismatch, we gather information from the connection on both sides and send it back for analysis. If you see a failure, let us know! If you’re in a corporate environment, share the middlebox information, if you’re on a residential network, tell us who your ISP is.”
TLS 1.3 gaining widespread adoption is important for the security of the Web, especially if the goal of encrypting the majority of traffic is to be achieved. The new version of the protocol has a simplified handshake between clients and servers which provides a significant performance boost.
TLS 1.3 also lowers the chance of deployment errors because it provides a much smaller selection of cipher suites—combinations of encryption and hashing algorithms—and all of them are currently considered safe. It removes insecure algorithms such as the RC4 stream cipher, CBC-mode ciphers and the SHA-1 hash function and also the RSA static key exchange mechanism.
The new protocol version only supports key exchanges based on ephemeral keys, such as Elliptic-Curve Diffie-Hellman (ECDHE), that provide forward secrecy and are more resilient to traffic decryption in private key compromise scenarios. In fact, this resilience to traffic interception has generated some contention between network operators and the protocol’s designers because TLS traffic inspection, which is required by many enterprises, is much more difficult to achieve at the network level with TLS 1.3.
