Fotolia
How are middleboxes affecting the TLS 1.3 release date?
Despite fixing important security problems, the official TLS 1.3 release date keeps getting pushed back, in part due to failures in middlebox implementations.
Transport Layer Security is the security mechanism that secures your username and password when you log in to your Gmail or Facebook account. Without TLS, it would be easy for people monitoring your web traffic to grab your credentials as you log in; the same goes for your payment card information when you make purchases on eBay or Amazon.
The Internet Engineering Task Force (IETF) is the standards body that oversees the development of the TLS protocol, which is overdue for an update. The last stable version of TLS is version 1.2, which was finalized in August 2008. Since 2008, there have been new developments in the area of security, and the IETF has been busy working on TLS 1.3.
TLS 1.3 has gone through 22 revisions since the first draft specification was published in April 2014. The different draft specifications are, in many cases, incompatible with each other. For example, a web browser that supports draft version 18 will not be able to connect to a website running draft version 21.
The current state is fairly stable, and so far, the latest changes have more to do with workarounds to enable real-world deployment. The latest changes have also included some implementation advice for areas such as traffic analysis, side-channel attacks and anti-replay, in specific scenarios.
Big changes in TLS 1.3
TLS 1.3 is a drastic change compared to TLS 1.2 and previous versions. It has been designed to be more secure and faster. A lot of the legacy cryptographic technologies that had been included for backward compatibility have been removed, including the MD5 hashing algorithm, as well as the obsolete Secure Sockets Layer protocol and RC4 stream cipher. In TLS 1.3, there are now a small number of mandatory ciphers that are considered very strong by today's standards.
The other area where TLS 1.3 has made improvements is speed. One of the key ways to measure user experience on a website is the round-trip time (RTT), or the time it takes for a message to be sent from a client to a server and for the server's response to be sent back.
If the client is geographically close to the server, then, usually, the RTT will be within reasonable range, measured in milliseconds. The shorter it takes, the better. The RTT value depends not only on geographic proximity, but also the number of hops that packets must traverse for that round trip, so being nearby doesn't necessarily mean having a low RTT.
However, for a client using a 2G or 3G data package in a country such as Mauritius to make purchases from a server in the United States, the TLS 1.2 handshake process can take several seconds to complete. TLS 1.3 speeds up the process by a factor of two, as it requires only one round trip to establish a TLS connection. This will help improve user experience for any website delivering content over HTTP using TLS.
Are middleboxes the only thing delaying TLS 1.3?
The delay in finalizing TLS 1.3 has more to do with deployment challenges. A known issue with the deployment of the new protocol has to do with middleboxes, the enterprise network security appliances whose function is to examine packets transmitted to or from the organization. Middleboxes are blocking internet traffic they don't understand, including TLS 1.3 traffic.
Despite the extensive tests that have already been done on TLS 1.3 with various implementations, it still faces issues with middleboxes.
Various parties, including Google, Mozilla and Facebook, have found a relatively high failure rate for middleboxes handling TLS 1.3 traffic. This has forced the designers of TLS 1.3 to go back to the drawing board and devise ways to work around those problematic middleboxes.
The other option to improve middlebox compatibility is to contact middlebox vendors and push them to update their equipment. There will be market pressure on those vendors that are late to catch up with TLS 1.3 support. Due to TLS 1.3's improved speed, there is a business case that more money can be made, and if middlebox vendors cannot adapt to their customers' needs, they are going to lose them.
What should implementers know about TLS 1.3 and middleboxes?
Implementers should look at the latest changes in TLS 1.3. Some of the web browser vendors are still lagging somewhat behind on the latest draft. They need to catch up. That is also the case for some TLS libraries that have begun implementing TLS 1.3, and are still stuck with draft 18.
Implementers should also test their code with middleboxes from different vendors in labs and contact the vendors if there are issues. My personal view is that we shouldn't add too many workarounds for middleboxes; the vendors should deliver better products and network engineers should upgrade the software on their equipment.
Realistically, many of those middleboxes won't be upgraded or replaced right away. My hope is that, in the future, the number of those problematic middleboxes will shrink, and the failure rate will decrease so that it's less costly and risky for websites to send content over TLS 1.3.
There was extensive debate regarding middlebox issues at IETF 100, which was held in Singapore last November. The proposed solution is to make TLS 1.3 look like TLS 1.2 session resumption to go through middleboxes that block TLS 1.3 traffic. This change was incorporated into draft 22, and it might take a few more revisions to finalize the specification.
It is difficult to give a definite timeline as to when the TLS 1.3 specification will be finalized. Different companies have different development cycles internally for implementing the latest TLS draft. Some of them can be late to report interoperability issues that may have been overlooked by others. The timing of their feedback will be critical to finalizing TLS 1.3.
About the author:
Loganaden Velvindron is an open source software developer and IETF participant working from Mauritius, a small island in the Indian Ocean.
