nobeastsofierce - Fotolia
TLS 1.3: What it means for enterprise cloud use
The latest draft version of TLS 1.3 is out, and it will likely affect enterprises that use cloud services. Expert Ed Moyle explains the impact on users and their monitoring controls.
If you're a security or network professional nowadays, particularly one in an organization that makes even moderate use of cloud services, you know just how important the Transport Layer Security protocol is to your overall security landscape.
TLS and its predecessor Secure Sockets Layer have defined secure communications on the internet for decades. They enable everything from secure browsing to e-commerce to secure banking. Together, they are the backbone of the connected world.
The current version of TLS, published in 2008 as RFC 5246, "The Transport Layer Security (TLS) Protocol Version 1.2," is starting to show its age in a number of ways. In particular, some TLS cipher suites -- the sets of algorithms and cryptographic primitives that define how data is encrypted and authenticated -- have become less secure over time due to advances in computing power and cryptanalytic techniques. Attacks have also emerged that have been facilitated by the standard itself.
In an attempt to both increase security of the internet overall, as well as to provide a stronger foundation for secure communications going forward, the next version of the TLS standard has been in draft form and under active discussion since early 2014.
From the point of view of cloud customers, much of the above might not seem to be directly germane to the work they do on a day-to-day basis. They will update their web servers and browsers to support the new standard as it gets implemented. It may sound easy, but nothing could be further from the truth.
In fact, the design decisions currently being discussed by the Internet Engineering Task Force TLS working group have the potential to affect cloud customers directly, and in a way much more substantive than it might seem on the surface. It is important for security practitioners to understand this because it could potentially directly impact monitoring controls and could influence decisions made today about specific monitoring controls.
What's the issue?
One of the design decisions made for TLS 1.3, as reflected in the current draft, is about a security property referred to as forward secrecy. This means that, should an attacker record a session today, they can't access the content of it in the future by compromising a future session key.
Now, it should be noted that there are cipher suites in TLS 1.2 that enable exactly this property. In fact, as of Nov. 4, 2017, only 6.8% of sites do not support it in some measure. In TLS 1.2, though, it is optional, and there are other ways to establish a session that do not provide forward secrecy.
For example, TLS 1.2 supports cipher suites that use a master key, which encrypts all session keys. So, if an attacker were to compromise the master key, they would gain access to any prior or future session data using that same master key.
This is a huge advancement in the overall security of the protocol. That said, there are monitoring controls that purposely use the older method so that they can use certain security-relevant tools, such as intrusion detection systems, application middleware, monitoring systems and other monitoring and detection controls. They work specifically because they know the master key used by upstream servers.
For example, an organization that controls both a web server running TLS 1.2 or earlier and a middleware application monitoring tool can be configured to specifically enable the device in the middle to intercept and decode the traffic. This method won't work under 1.3.
Why this matters to your organization
From a practical point of view, this matters for two reasons. First, it could potentially impact controls that might already be in place; for example, if you use a middleware product that passively examines TLS traffic, like one that specifically requires access to a master key to operate. There are situations where you might have a regulatory reason to monitor in this way; for example, in financial institutions where monitoring of certain data exchanges is required.
Keep in mind that although TLS 1.3 is still in draft form, support for it is actively being rolled out. If you have these controls in place, now is the time to start thinking through how you will handle them.
In fact, it is a useful strategy to think through any monitoring control that involves unwinding TLS sessions. That's true both for passive monitoring and proxying -- such as TLS interception or HTTPS inspection. Not only has recent research highlighted security challenges with HTTPS inspection -- including a US-CERT advisory on the topic -- but practical issues will also arise as the TLS 1.3 rollout occurs.
For example, in late February, a rollout of TLS 1.3 in Chrome 56 impacted users of Blue Coat's gateway. Thinking it through now is not only a good idea to minimize the possibility of potential disruptions, but it's also good security practice.
The second reason why this matters is that it could inform purchasing decisions that you make if you are considering bolstering your monitoring capability. As we move to more intelligence-driven security methods, it can incentivize us to be more aware and alert to potential exfiltration of data and attacks against services we operate.
Likewise, as the technology we employ becomes more externalized via the cloud, it behooves us to implement monitoring and detective controls, and for our cloud providers to do so, as well.
So if, like most of us, you have better detection and monitoring capability on your radar, thinking through how that monitoring capability is implemented -- and whether it will perform as advertised in a TLS 1.3 world -- is important. An honest, brass tacks discussion with potential vendors, service providers or potential cloud partners about how monitoring capability can be impacted by TLS 1.3 is a good idea.
It will, of course, be some time before TLS 1.3 is ubiquitous. Likewise, backward-compatibility with 1.2 will probably continue for quite some time. With an issue as large as this one, the planning and preparation time will almost certainly be needed -- and welcome -- by those it impacts.
