Many people in the information security field strongly suspected that government eavesdropping was pervasive. But Edward Snowden’s leaks about the NSA and programs such as PRISM have thoroughly confirmed these suspicions. The latest NSA proposals to the White House (reported by The Washington Post) for a “front door” to our mobile devices has let us know that these and other agencies are unrelenting in their efforts to compromise our privacy. Government agencies are not alone in their desire to eavesdrop. The so-called Superfish root certificate installed on Lenovo laptops enabled pervasive sniffing by adware networks.
These eavesdropping mechanisms, even on encrypted data streams, are largely possible due to weaknesses in certain types of SSL or TLS encryption, mainly the RSA key exchange.
Enter a technique called Forward Secrecy (or sometimes Perfect Forward Secrecy). It foils man-in-the-middle (MITM) attacks by “double encrypting” the TLS sessions between the client and the server. This double encryption is achieved by adding a Diffie-Hellman Ephemeral (DHE) key exchange or its Elliptic Curve variant (ECDHE) on top of the existing TLS handshake.
Ivan Ristic at Qualys covers in great detail the use of DHE and ECDHE over at SSL Labs. Ristic notes that both DHE and ECDHE come with a performance impact but, for many distributed architectures or those with dedicated hardware accelerators for TLS, the impact is usually not significant. Certainly, we should take care in enabling or prioritizing cipher suites with more performance overhead, but let’s assume we’ve already scaled the environment sufficiently to absorb the cost of PFS.
Even YouTube and Netflix streams are TLS-encrypted by default, so there is no question that the vast majority of traffic will or should be encrypted before much longer. The question becomes:
How do we maintain visibility and security controls when everything is encrypted, especially with strong ciphers?
Ristic mentions the reliance of legitimate security solutions such as web application firewall (WAF) and intrusion prevention/detection system (IPS/IDS) on the weakness of the RSA key exchange to MITM sniffing. As more organizations have begun earnest efforts to support forward secrecy on their Internet-facing web applications, IPS and WAF solutions have “gone blind” when deployed in a passive tap or layer 2 “bump in the wire” mode of deployment. These deployment modes were desirable in the past because they provided visibility with minimal to no risk of traffic disruption. Ironically, enforcing the use of PFS ciphers can cause traffic disruptions if the “bump in the wire” doesn’t gracefully handle seeing a cipher that it doesn’t support.
Many of these security solutions can be reconfigured to support forward secrecy via DHE and/or ECDHE, but only as an inline reverse proxy. Moving from a passive or out-of-band solution to an inline reverse proxy increases the likelihood of removing that security measure altogether. When a solution increases the risk of outage or imposes too many scalability limits, availability and performance always trump security.
We will need to seek out novel architectures to maintain visibility with sensors such as WAFs and IPSs/IDSs, which may not have advanced capabilities for TLS. The vital components of a robust SSL/TLS visibility architecture are:
- Robust termination endpoints, enabling scalability and progressive, flexible cipher and protocol support
- A management solution for our proliferating numbers of certificates and keys, so that we might easily know:
- When a certificate expires
- Which certificates still have 1024-bit keys or are SHA1-signed
- Where all certificates and keys are installed
- A secure, auditable mechanism for key storage, such as a Hardware Security Module, or HSM
The first component above is the key to enabling third-party solutions that are blinded by the latest protocols such as TLS 1.2 or the forward secrecy ciphers DHE and ECDHE. These encryption endpoints need to be able to scale to support multiple passive sensors or taps such as IPS or WAF, potentially along with re-encryption after IPS or WAF processing. Additionally, the encryption endpoint should be able to enforce and prioritize ciphers, protocols, and extensions.
Awareness of SSL and TLS vulnerabilities and eavesdropping are at an all-time high, and attacks are evolving to target the SSL and TLS protocols themselves. In this climate, no one wants to publish a web application that achieves poor grades on SSL Labs. The TLS termination endpoint now serves not only as a means of encryption offload and visibility, but also as an enforcement point where organizational policies for good, strong encryption can be implemented, audited, and enforced. An SSL/TLS firewall for logging, reporting, and management of encryption is a logical evolution in how we architect our security service chains, especially as we implement stronger encryption via techniques like Perfect Forward Secrecy.
[su_box title=”About Brian A. McHenry” style=”noise” box_color=”#0e0d0d”]
Bio: As a Security Solutions Architect at F5 Networks, Brian McHenry focuses on web application and network security. McHenry acts as a liaison between customers, the F5 sales team, and the F5 product teams, providing a hands-on, real-world perspective. Prior to joining F5 in 2008, McHenry, a self-described “IT generalist”, held leadership positions within a variety of technology organizations, ranging from startups to major financial services firms.
Twitter: @bamchenry[/su_box]
About the Author
The opinions expressed in this post belongs to the individual contributors and do not necessarily reflect the views of Information Security Buzz.
