Security Experts:

Fitting Forward Secrecy Into Today's Security Architecture

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.

Forward Secrecy Configuration

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 spent years and years telling everyone that TLS 1.2 was already fast, so why bother upgrading?

TLS Proxy Diagram

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.

view counter
David Holmes is an evangelist for F5 Networks' security solutions, with an emphasis on distributed denial of service attacks, cryptography and firewall technology. He has spoken at conferences such as RSA, InfoSec and Gartner Data Center. Holmes has authored white papers on security topics from the modern DDoS threat spectrum to new paradigms of firewall management. Since joining F5 in 2001, Holmes has helped design system and core security features of F5's Traffic Management Operating System (TMOS). Prior to joining F5, Holmes served as Vice President of Engineering at Dvorak Development. With more than 20 years of experience in security and product engineering, Holmes has contributed to security-related open source software projects such as OpenSSL. Follow David Holmes on twitter @Dholmesf5.