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
Source: National Cyber Security Centre
