Transport Layer Security (TLS) is fundamental to the security of the Internet. Proposed changes to the protocol are generating extensive controversy within and outside the security industry. Rather than getting into cryptographic specifics, this post focuses on the root of the controversy, and why we believe TLS 1.3 should proceed with the full support of technical professionals.
What is TLS 1.3? – Transport Layer Security (TLS) is the primary protocol for securely sending information over the Internet. It is the successor to SSL (Secure Sockets Layer) and built into every web browser and web server, as well as many other applications. Nearly every website in the world uses TLS to one degree or another to protect communications – including signing into a site with a password, banking, and reading email. TLS is also embedded into many other applications and the guts of the Internet. You use it every day. If you are reading this on our website you used TLS to see this page. If you checked your email today, TLS is what prevented someone on the Internet from reading it.
If you are completely non-technical, think of it as a security envelope for your data. But TLS does much more.
TLS 1.3 is a proposed draft to update the current version (TLS 1.2 – surprise!) and improve security and performance. As with any software, TLS is never ‘perfect’, and needs updating from time to time. For example one change cuts the window to initiate a secure connection in half. 1.3 also simplifies the kinds of encryption it supports to eliminate known security vulnerabilities. TLS 1.3 is already supported in some web browsers, even though the standard isn’t final.
Why is TLS 1.3 controversial? – Version 1.3 eliminates a security weakness of TLS 1.2, but that exact weakness is used by many organizations to monitor their networks. Some organizations and security vendors want to retain it so they can continue to use existing technique to monitor traffic.
We need to choose between better inherent Internet security and supporting a widely used monitoring technique.
Monitoring itself is not inherently bad. Common tools like Data Loss Prevention rely on peering into encrypted connections on corporate networks to identify sensitive data being accidentally or maliciously exposed. Other tools sniff connections to recognize attacker activity, and then either block or alert. It’s a form of wiretapping, but one widely used as part of security programs rather than for spying – although it can obviously be used for both.
Security is always a balancing act, so we often face these difficult decisions. Fortunately in this case there are alternative techniques to achieve the same security goals, so our position is that we should not keep a vulnerability in a core Internet protocol just to support existing security tools.
The controversy is about security vs. cost. Existing monitoring approaches can support 1.3, so a possibly higher implementation cost should not excuse a security reduction.
What exactly is the security weakness TLS 1.3 eliminates? – Version 1.3 eliminates support for an older way of setting up encrypted connections using a master key. It could enable someone with a copy of the master key to sniff all encrypted traffic. They could also decrypt any previously recorded traffic protected with that key. The proposed updates to TLS use a different key for every connection, so there is no master key which could allow unrestricted monitoring. We call this Perfect Forward Secrecy, if you want to look it up.
This is a pretty big weakness, which has been used in attacks. Unfortunately it’s also used by legitimate security tools for more efficient monitoring.
Does TLS 1.3 reduce enterprise and government security? – No.
It changes how you need to implement some security. It will cost money to update to new kinds of systems to perform the same kinds of monitoring. It will require rethinking how we do some things today. But it does not eliminate the ability to achieve security objectives.
Organizations that need to monitor traffic can do so with four techniques:
- Active interception (man in the middle) techniques.
- Using software to capture traffic on endpoint systems, instead of on the network.
- Capturing data on Internet servers. For example, some cloud services allow you to track all employee data and activity.
- For servers you control, you can still use TLS 1.2. It will likely be supported for many years.
Do we really need to remove passive monitoring from TLS 1.2? – Yes.
We face a simple choice: we can make network sniffing attacks harder, or easier. We can improve security, or leave a known vulnerability. Our position is that we should always choose stronger security. The Internet is littered with the consequences of choosing weaker options, especially for encryption.
Support for passive monitoring of encrypted connections may help some aspects of an organization’s security program, but only at the expense of long-term security. Attackers, criminal and otherwise, can leverage this to spy on organizations, individuals, and governments. They can potentially record traffic on networks and then decrypt it later… even weeks, months, or years later. We have seen this exploited in criminal and government attacks – it is not a theoretical vulnerability.
What is the impact if TLS 1.3 is adopted? – There won’t be any immediate impact in most cases.
TLS 1.2 is still completely supported and will be for a long time. As online services start adopting TLS 1.3, organizations which rely on passive sniffing of encrypted connections may start losing visibility into those connections. Organizations which want to maintain this visibility will need to update their tools and techniques.
But the entire Internet won’t shift to TLS 1.3 overnight, so there is time to make the transition.
Transport Layer Security 1.3 brings important security improvements to one of the most foundational technologies used to protect Internet communications. It eliminates a form of passive sniffing that, although used for legitimate security purposes, also weakens Internet communications. We would rather have an inherently secure Internet than keep a security weakness just to support existing security tools and practices which can be replaced with new techniques to achieve the same goals.
This is a conflict between security and cost. Sometimes costs wins, but time and time again we suffer the consequences of compromising security to reduce cost. Considering how absolutely essential TLS is to a safe and secure Internet, leaving in a known weakness to save a little money and gain convenience for a small subset of the world is simply unjustifiable.
Comments