Blog post

TLS 1.3: better for individuals - harder for enterprises

Created:  09 Mar 2018
Updated:  09 Mar 2018
Author:  Ian Levy
Secure communications

The Secure Sockets Layer (SSL) protocol was first introduced in 1994 by Netscape. It's gone through a number of revisions  - notably a name change to Transport Layer Security (TLS) - and has become probably the most widely used encryption protocol on the Internet.

It was originally introduced to protect payment and personal information to support the burgeoning e-commerce platforms on the web. However, over the last few years, it has grown to encompass pretty much everything on the Internet. There are almost no commonly-used sites or services that don’t support encrypted connection. Generally speaking, that’s a good thing. However, phishing sites are also using TLS to make them more believable to users, and some malware uses the TLS protocol to hide its nefarious activities.

Many enterprises have security appliances that seek to look into TLS connections to make sure that the enterprise security is appropriately protected. Whilst it sounds like a magic box that can 'break' encryption, it’s not. It only works because an enterprise security appliance can act as its own certificate authority that the enterprise clients will trust; it doesn’t affect anyone else. Most of these appliances usually whitelist a bunch of sites (including healthcare, banking and other services that hold sensitive personal data) because the risk to enterprise security doesn’t warrant the risk of the enterprise knowing really sensitive stuff about its employees. They also drop out of proxying connections when they determine the risk is low. Lots of regulatory regimes make it a requirement for regulated industries to inspect traffic as it leaves their network.

The IETF will soon publish version 1.3 of the TLS specification. Version 1.3 addresses a number of things to make the protocol fit for the future:

  • It removes some old and creaky cryptography which we really shouldn’t be using anymore.
  • It makes a bunch of attacks less likely.
  • It adds some more robust connection privacy protection, intended to protect individuals from 'pervasive monitoring'.

The challenge is that these protections will also make the enterprise security model much, much harder. There’s two specific things that I think will have a negative impact on enterprise security.

The first is that it’s impossible to whitelist sites anymore because server certificates (the things that authenticate a site) are encrypted. So, your appliance will be unable to work out (for example) whether you’re communicating with your bank, or if malware on your machine is talking to its criminal masters, without breaking the connection. That wouldn't be a problem if you could break the start of a connection and then drop out when you find out it’s a low risk (or sensitive site). But that brings us to the second problem; you can’t do this in TLS 1.3. Once you proxy a connection, you have to proxy it until it’s done.

What this means is that enterprises will have to proxy each and every TLS 1.3 connection - whether they need to or not - and for the entire duration of the connection. This reduces the privacy of the employees in that enterprise, massively increases equipment and power costs, and probably increases overall technical risk for the enterprise and its employees. Clearly, that’s not a great outcome.

At the moment, this isn’t a problem as enterprises can just say that they’ll only support TLS 1.2, allowing them to continue managing their enterprise risk. However, it’s only a matter of time before some popular service adopts TLS 1.3 exclusively, at which point enterprises then have to make a choice about denying access, or losing the ability to manage their enterprise risk fully.

Some will say that endpoint security will make up for what we lose. But we’ve seen what happens with reliance on just endpoint security, and that’s why we all prefer layered defences. There’s likely to be a bunch of new cyber security products claiming to be able to work out whether a TLS 1.3 connection is good just by looking at the encrypted packet flows. Such products are unlikely to defend against a competent adversary for long:

  • We’ve seen attackers mimic traffic profiles to hide in the noise for years, and it will be easier for them in this situation.
  • Server Name Indicators are still in the clear, but they’re a request from the client, not tightly bound to the server we’re actually interacting with.
  • DNS names are still available, but that may get harder depending on enterprise architecture and whether encrypted DNS becomes mainstream, through a standard called DPRIVE.
  • Making risk judgements based on IP address is very weak and IPv6 will change that as well, likely for the worse.  
  • As IoT hubs start to appear, it may end up being harder for users to understand what’s being sent by their things if the hubs can’t do selective proxying.

It’s almost certainly true that investigation of enterprise cyber security incidents will be harder than it is today, since a good proportion of the data we use to detect compromised devices will be harder to get. So while TLS 1.3 undoubtedly provides better protection for individuals, it certainly looks like it’ll have a negative effect on enterprise security, if it becomes effectively mandatory.

There needs to be work done on both national and international regulations to understand the impact of this change. For example, it looks like TLS 1.3 services are probably incompatible with the payment industry standard PCI-DSS and the US health industry requirements under HIPAA. There are some other obvious conflicts, and certainly some we've not even thought of yet. We also need more research into how we continue to provide decent enterprise risk management as TLS 1.3 becomes the standard over the coming few years.

I’m expecting people to accuse me of being an intelligence agency stooge who’s against encryption. We've said the NCSC would be transparent and evidence-based, and so far the evidence suggests that TLS 1.3, overall, will be bad for enterprises. We appear to be in the weird position where well-designed, well-intentioned crypto will actually have a downside for cyber security. I’m not asking for the standard to change – it’s almost certainly too late for that. But work needs to happen quickly to ensure that attackers don’t get a massive leg-up.

 

Ian Levy
Technical Director, National Cyber Security Centre

3 comments

Ian Levy - 12 Mar 2018
This blog was intended to raise awareness in the enterprise security community about upcoming changes to TLS. As you’d expect, it got some comments. Adam Langley probably best summed up the majority of it in his blog (https://www.imperialviolet.org/2018/03/10/tls13.html). Now, I don’t agree with everything in Adam’s blog (much as he doesn’t agree with everything in mine) and that’s fine because there should be discussion on topics as important as these. But I think a couple of clarifications could be helpful.

Firstly, I agree with Adam’s point about some cyber security products (including TLS proxies) being bad for security overall because they’re poorly conceived or poorly built. We’ve talked about that before. But that’s not true for all of them; there are some good products out there.

I don’t agree that proxying is a fundamentally flawed strategy in a realistic enterprise environment. Plenty of enterprises do it very successfully, and many of them rely on it. The important part here is ‘realistic enterprise environment’; much as we’d love to have idealised architectures, in most places we’ve got years of legacy decisions, technology and processes to deal with. And that takes time to fix.

The reference to regulatory standards wasn’t intended to call into question the ability of TLS 1.3 to meet the data protection standards. It was all about the potential to affect (badly) audit regimes that regulated industries have to perform. Right or wrong, many of them rely on TLS proxies as part of this, and this will get harder for them.

(comment 1 of 2)
Ian Levy - 12 Mar 2018
On malware, the authors are infinitely inventive and none of us can 100% predict what we’ll see in the future. What I do know is that there’s plenty of scope for them to hide differently (and probably more effectively) under TLS 1.3. Also, proxy logs are important in investigating incidents and there will be a lot less in them that’s of use. Again, that’s going to make response harder.

This is an important topic that attracts different views, but rather than getting into a nuanced argument about TLS exchange, I’ll give it another go.

I’m not saying TLS 1.3 is bad.

I’m not saying it should be stopped.

I’m not saying that the changes aren’t all rooted in good technical security.

I’m merely saying that it’s going to make a bunch of enterprise related security stuff harder. So, given that, we need to do work collectively to work out how to adapt in regulatory, technical and policy worlds.

(comment 2 of 2)
NCSC Communications Team - 11 Sep 2018
This blog is now closed to comments.

Was this blog post helpful?

We need your feedback to improve this content.

Yes No