The damage a hacker can do after discovering a server’s private encryption key is about to shrink considerably. That’s thanks to important improvements in the coming Internet Engineering Task Force (IETF) Transport Layer Security (TLS) standard for Internet security. Notably, while prior versions had optional forward secrecy, TLS 1.3 mandates forward secrecy for all TLS sessions. Cisco supports using forward secrecy with TLS, and here’s why.
Security Fans are Forward Secrecy Fans
The goal of forward secrecy is to protect the secrecy of past sessions so that a session stays secret going forward. With TLS 1.2 and earlier versions, a bad actor who discovered a server’s private key could use it to decrypt network traffic that had been sent earlier. For example, suppose someone started recording encrypted traffic in our network on January 1st and then discovered a server’s private key on January 31st. That person could decrypt all of the server’s traffic and make off with the credit card numbers we entered yesterday, our lab results from last week, and our team’s patent application from the week before.
With the forward secrecy in TLS 1.3, there’s no longer a single secret value that will decrypt multiple sessions. Instead, TLS 1.3 uses the Ephemeral Diffie-Hellman key exchange protocol, which generates a one-time key that’s used only for the current network session. At the end of the session, the key is discarded. While attackers can still record and store encrypted network traffic, to decode it they need the unique key for each session. A session key won’t decode data sent during an earlier session or help an attacker discover future session keys.
Forward secrecy is a best practice for security—which is why we’re all for it.
Other Effects of Forward Secrecy
Now, forward secrecy will require some changes to current network security practices. For example, security and IT teams need new ways to discover and block malware and advanced threats hidden in web traffic. Deep-packet inspection won’t be effective with ephemeral Diffie-Hellman key establishment, and passive monitoring won’t work with encrypted handshake messages. So it’s time for network security vendors to get creative. For more on this, see our IETF Internet-Draft, TLS 1.3 Impact on Network-Based Security.
Our Investments in Security for Encrypted Traffic
In fact, we’ve been preparing for TLS 1.3 and forward secrecy for some time by investing in new ways to identify threats in encrypted traffic. Here are a few:
Encrypted Traffic Analytics (ETA) detects threats in encrypted traffic using network analytics and machine learning. ETA does not use deep-packet inspection; instead, it analyzes visible telemetry information from Cisco switches and routers, such as packet lengths, arrival times, and initial handshake data packets.
Observable Networks, which Cisco acquired in July 2017 (and I founded), detects threats by observing the behavior of endpoints based on telemetry from metadata such as NetFlow. It uses machine learning to identify changes that could be early indicators of compromise. Observable Networks is now Cisco Stealthwatch Cloud.
Advanced Malware Protection (AMP) for Endpoints operates on the endpoint itself—your laptop, phone, etc.—where files and payloads are created and stored. As an endpoint technology, AMP can inspect communications even when the network “goes dark” with encryption.
Cisco Umbrella can warn you that a website is malicious before you connect. Umbrella looks at DNS traffic instead of TLS, so it can still gather the information it needs even as TLS encryption gets stronger
