By Peter Rietveld, senior security consultant at Traxion. If you think Heartbleed or Diginotar was a real crisis in crypto – you haven’t seen nothing yet. The next major crisis is on the horizon. And it is, well, kind of complicated. As usual.
TLS, the encryption protocol formerly known as SSL, has become the world’s most used cyber security mechanism. As a reaction on growing privacy (Facebook) and security concerns (Snowden, Huawei), up to 90% of all internet traffic is now encrypted, mostly using TLS1.2. This major change took only a few years. Despite formal adoptions of security concepts as Zero Trust or, longer ago, the Jericho Manifesto, enterprise networks are way behind. Generally, on the corporate network most traffic is unencrypted. And where it is encrypted, it uses the old TLS1.0 version. The pending crisis is that this old encryption will be blocked in the browser as of early 2020. Blocked without explanation; users will see “Access Denied”. Administrators will see the same in the logs: no explanation
Adoption of the TLS1.0 successor, TLS1.1 in practice never really took off so the 1999 vintage 1.0 is still leading in most corporate networks. TLS1.1 will also be blocked next year, together with its predecessor. TLS 1.2 is only just beginning to take over in the latest versions in the enterprise IT landscape particularly in the big application landscapes (built with Oracle, SAP, WebSphere and the like). In many cases the application server must just be upgraded, which brings along an upgrade of the java version which in turn forces refactoring of the application code. Something complex requiring specialist knowledge and taking time. And thus expensive. Most organization haven’t prepared. Caught pants down.
In October 2018 Apple, Microsoft and Google announced that they will no longer support for TLS 1.1 and TLS 1.0. All of the major browsers – Apple Safari, Google Chrome, Mozilla Firefox and Microsoft Edge & Internet Explorer – will all be dropping support for TLS 1.1 and TLS 1.0 by early 2020. The transition to TLS1.2 will finally be enforced, 10 years after the original introduction.
TLS1.2 is in practice also mandatory for http2 and a growing number of other modern technologies. The Token Binding protocol will close the gap with bearer tokens – cookie theft included. The internet is becoming a safer place than the average enterprise LAN. Home users run all patches on modern operating systems and are reasonably protected. Enterprises are still struggling with the 2005 standards, fighting with NTLM and SSH and fearing the end of Windows 7 and Oracle 10.
This will bring a meltdown, a cryptogeddon if you like. If no compatible cipher can be negotiated, there will be no session. The system can’t be accessed. Smaller features will break as they were overlooked, in unexpected places. For instance, Active Directory trusts, even when running the newest version 2019, will break. Well, now these are known Microsoft will probably fix them. But there’ll be others. Plenty of them.
That is bad. Really bad.
If your organization still wants to use older application servers after June next year, the logical option is to use an old browser. Enterprises will be telling their users that they can’t use their home devices as it is insecure yet force the use of unsupported stone-age browsers such as Internet Explorer 9 on nostalgic windows7 computers. Mobile devices can’t update either – enterprises must actively block security updates. As this is very difficult and expensive to manage, the easiest and thus most likely outcome of the move to TLS1.2 is that enterprises will drop the use of traffic encryption altogether. That’d be hackers’ heaven.
Not what we want, either.
With TLS1.3 introduced last years, – with a look at a long list of breaches and vulnerabilities – the pace of upgrades is picking up and every should follow. Many related technologies are also emerging – and may or may not become a mandatory standard. Token Binding, Unicode certificates, DNS over TLS, encrypted SNI and certificate Transparency are demanding our attention. If we don’t act our users will see security warnings all over. It will feel like a bog fire with increasing flare ups.
Note that TLS1.3 isn’t even the biggest issue for Enterprise security – the underlying transition to newer ciphers is. The new key establishment ciphers block the Man-in-the-Middle attack with the ‘Perfect Forward Secrecy’ capability. When these ‘PFS’-ciphers are enabled in TLS1.2, you have what PCI-DSS standards now describes as ‘Late TLS’. These ciphers aren’t part of the original TLS1.2 stack, and generally updates add them but do not enable them. The original cipher suite is now referred to as Early TLS. To be compliant, only Late TLS should be enabled. The Dutch Authority on Person Data, enforcer of GDPR, has taken this line also: if a system handles person data it must follow the 2019 NCSC guideline for TLS i.e. late TLS with PFS.
When adopting “Late TLS 1.2” not only the Man-In-The-Middle attacks by bad guys are blocked – unfortunately many enterprise security systems are also broken. Any system decrypting network traffic to find malware or block attacks technically performs a man-in-the-middle too. So CASB, IDS, SIEM, antivirus, API gateway and any other type of application layer firewall is very likely to break, too. Most people think this is specific to TLS1.3 which is ‘somewhere in the future’. This is what caused the delay to the formalization of the TLS1.3 standard last year. But it is just as present in late TLS as soon as only PFS-ciphers are used. Which is mandatory, either now or very soon.
Considering the growing complexity of the protocol, and the scarceness of knowledge, delay spells disaster. For security practitioners and suppliers, it is time to study. And for large organizations now is a very good time to start a major program. For even when we still have a few years for the migration, remember that we were unable to migrate to TLS1.2 in more than 10 years.