Enterprise Network Monitoring Needs Could Hamper the Adoption of TLS 1.3
The upcoming version of the Transport Layer Security (TLS) protocol promises to be a game changer for web encryption. It will deliver increased performance, better security and less complexity. Yet many website operators could shun it for years to come.
TLS version 1.3 is in the final stages of development and is expected to become a standard soon. Some browsers, including Google Chrome and Mozilla Firefox, already support this new version of the protocol on an opt-in basis and Cloudflare enables it by default for all websites that use its content delivery network.
TLS 1.3 is a major overhaul of the technology that underpins web and email encryption. One of the biggest improvements in the new version is a simplified handshake between clients and servers. Negotiating the session key used to require two message round-trips, but now requires only one, giving TLS 1.3 connections a significant performance boost.
Another important change is the removal of many cryptographic algorithms that were known to be insecure, including the RC4 stream cipher, CBC-mode ciphers and the SHA-1 hash function. TLS 1.3 allows for only five “cipher suites” — combinations of encryption and hashing algorithms — to be used and all of them provide strong security, so it’s impossible to make mistakes. By comparison, TLS 1.2 had more than 20 possible combinations, leading to many deployments that were vulnerable to various known attacks.
But there’s one particular change in TLS 1.3 that has caused some controversy in recent months, and that’s the removal of RSA and other key agreement protocols that rely on static keys.
With RSA, the client generates the master secret that will be used to establish a session key and sends it to the server during the connection handshake after encrypting it with the public key extracted from the server’s digital certificate. The server then uses its corresponding private key to decrypt the client message and extract the secret.
This reliance on a single private key to protect all handshakes has come to be viewed as a security weakness in recent years, especially after revelations that nation states engage in mass internet surveillance. With this set-up, if attackers obtain a server’s private key, they could decrypt not only future but also past messages between users and that server, assuming those encrypted exchanges were previously recorded and stored somewhere.
While forward secrecy is great for security, it’s incompatible with the network monitoring systems that many companies have in place precisely because it makes the passive decryption and inspection of TLS traffic very difficult.
To mitigate this risk, TLS 1.3 only supports key exchange protocols like Elliptic-Curve Diffie-Hellman (ECDHE) which use ephemeral keys instead of static ones. These protocols have a cryptographic property called “forward secrecy” that prevents the decryption of past messages even if the server’s private key gets stolen. In fact, the server’s digital certificate is only used to verify the server’s identity and plays no role in protecting the handshake and its secrets.
It turns out that while forward secrecy is great for security, it’s incompatible with the network monitoring systems that many companies have in place precisely because it makes the passive decryption and inspection of TLS traffic very difficult. Many companies, especially those working with sensitive data, might be under a regulatory requirement to encrypt traffic to their web applications and to monitor that traffic for security threats at the same time.
With TLS 1.2, organizations could install the private keys of their TLS servers on firewalls and other monitoring tools that would then be able to decrypt and inspect the traffic. But to do that with TLS 1.3, it would require exporting all the ephemeral keys on the fly as they get generated on web servers for every single connection.
That doesn’t scale very well and could become a huge administrative burden on large networks.
Network operators now want to make changes to the TLS 1.3 specification, even though it’s very late in the design process, according to Stephen Checkoway, an assistant professor in the Department of Computer Science at the University of Illinois at Chicago. In recent months, they’ve approached the TLS Working Group at the Internet Engineering Task Force (IETF), the body that develops internet standards, and asked for a mechanism to be included in the new protocol that would allow them to perform the kind of passive traffic inspection they need.
Doing this would likely mean sacrificing the mandatory forward secrecy property of TLS 1.3, which, in the view of some people, would weaken the standard and would make wiretapping possible, something that the IETF wants to avoid in general.
Other people have a more pragmatic view, arguing that if met with refusal, network operators will eventually devise their own method for traffic inspection that might involve making non-standard modifications to TLS 1.3 implementations. As such, they believe it would be better for such a mechanism to be designed in public under the IETF’s supervision, rather than to end up with different proprietary solutions that would hurt TLS even more.
A proposal for a mechanism that allows the use of static keys with elliptic-curve Diffie-Hellman has already been submitted for consideration as a standard. Its implementation would require some configuration changes to TLS servers and network monitoring tools but would be compatible with TLS 1.3 clients, such as browsers.
“Such monitoring of the enterprise network is ubiquitous and indispensable in some industries,” the mechanism’s authors wrote in their proposal. “This monitoring is required for effective and safe operation of enterprise networks. Loss of this capability may slow adoption of TLS 1.3.”
And indeed, one argument against accommodating the traffic monitoring needs of network operators in TLS 1.3 is that they can continue to use TLS 1.2 on their servers and networks. After all, servers often support multiple versions of TLS at the same time to be compatible with older clients. Similarly, clients support multiple TLS versions to be compatible with older servers, so TLS 1.2 will not disappear anytime soon.
According to data from the SSL Pulse project, out of the world’s most popular 140,000 HTTPS-enabled websites, 93 percent still support TLS 1.0, which was created in 1999. Around 84 percent of them also support TLS 1.1, which was released in 2006, and 87 percent support TLS 1.2.
“The sense of urgency from the operators and the pragmatists is, I believe, unwarranted,” Checkoway said in a blog post about the current debate. “Yes, switching to TLS 1.3 will prevent operators from doing precisely what they’re doing today; however, there is currently no need to switch. TLS 1.2 supports their use case and TLS 1.2, when used correctly, is secure as far as we know.”
Of course, this also means that many organizations might decide not to enable TLS 1.3 on their web servers in the years to come.
Feature image by Graham Holtshausen via Unsplash.
