Forward Secrecy’s day has come – for most. The cryptographic technique (sometimes called Perfect Forward Secrecy or PFS), adds an additional layer of confidentiality to an encrypted session, ensuring that only the two endpoints can decrypt the traffic. With forward secrecy, even if a third party were to record an encrypted session, and later gain access to the server private key, they could not use that key to decrypt a session protected by forward secrecy. Neat, huh?
Forward secrecy thwarts large-scale passive surveillance (such as might be conducted by a snooping nation state or other well-resourced threat actor) so it is seen a tool that helps preserve freedom of speech, privacy, and other rights-of-the-citizenry.
It is supported and preferred by every major browser, most mobile browsers and applications, and nearly 90% of TLS hosts on the Internet, according to a recent TLS Telemetry report (PDF). The crypto community applauds forward secrecy’s broad acceptance today.
Of course there’s a snag, for some.
While forward secrecy foils passive surveillance, it also complicates inspection for nearly every SSL security device currently in existence. High security environments with requirements for encrypted network data even within the datacenter, inspect SSL traffic by sharing the RSA private keys throughout their network. That system no longer works with forward secrecy.
In this common configuration, without forward secrecy, inbound traffic can be inspected at any or every point within the data center. Malware can be found before it reaches gets uploaded to a repository. Anti-fraud measures can be taken against automated transactions. Brute force logins can be detected and mitigated. SQL injections can be filtered out by web application firewalls.
If forward secrecy were to be enabled in this common configuration, only the endpoints (the web user and the application server), can decrypt the traffic, leaving all the security inspection devices blind.
As a result, many high-security environments, like banks and other financial services, don’t offer forward secrecy. Which was fine until TLS 1.3, which has no option except for forward secret ciphers. The banking community was unable to convince the IETF TLS committee to accommodate their architectures during the design of TLS 1.3.
TLS 1.3 has had other issues as well, as documented by Nick Sullivan and others, and as a result, is not used by anyone outside of Cloudflare, who helped design it.
So what’s the fix?
Short and Long Term Solutions
If TLS 1.3 starts gaining traction, architects in high-security environments are going to have to consider how to fit it into their existing architectures. Your intrepid writer thinks there are only a handful of possibilities.
Stick with TLS 1.2. Remember TLS 1.1? No one ever used it, even though it was technically superior to TLS 1.0. There’s a chance that no one will adopt TLS 1.3 either, because TLS 1.2 doesn’t have any real pressing issues, such a protocol vulnerabilities, against it. Sure, TLS 1.3 is slightly faster, but the website IsTLSfastYet.com spent years and years telling everyone that TLS 1.2 was already fast, so why bother upgrading?
Proxy TLS 1.3 to TLS 1.2. In the medium term, solution architects could deploy a TLS 1.3 proxy. The proxy will communicate TLS 1.3 with the end user, and then establish a new TLS 1.2 session through the data center to the servers. Your intrepid writer has been telling people for a couple of years that this the short term solution, but he’s glad to find out that the IETF TLS committee is hinting that this is very likely the long term solution.
Skip to Post-Quantum TLS 2.0 (PQTLS2?). Many in the crypto community are worried that an encryption-breaking quantum computer will be here within five years. NIST is taking quantum seriously, and has accelerated the selection of post-quantum encryption algorithms to a mere two year deadline (which started last November). So around 2020, or even 2022, we may have a new version of TLS that has support for post-quantum algorithms.
Actually there’s a chance that TLS 1.3 could already accommodate a PQ handshake, but given the awkward dance that TLS 1.3 is already going through just to “fit in” there’s a good chance it will change again. And when it does, let’s hope that it “fits in” better with security architectures. Or that those architectures have matured to better inspect TLS traffic.