SHARE
Security / February 11, 2019

Don’t TLS 1.3 Naked – The Risks and Benefits of Traffic Decryption Decoded for You

Updated October 14, 2021.

Certain security best practices stand out over the rest as obvious must-do’s: back up your data, apply the latest patches, mandate multi-factor authentication and educate your users. While not a must-have even just a few years ago, inspecting and protecting encrypted traffic is now nearing the top of security best-practices priorities in 2019.

Version 1.3 of the Transport Layer Security (TLS) protocol was published by the IETF in August 2018. Fun fact: It was ten years to the month after TLS 1.2 was published. Here’s our CTO Shehzad Merchant’s blog on the topic. Among other improvements, the new TLS version speeds up handshakes between client and server, makes it harder for admins to misconfigure and helps prevent breaches of the server’s secret key from being used to decrypt historical traffic.

However, TLS 1.3 also eliminates the use of RSA and other non-PFS public key exchange algorithms and encrypts the certificates used for handshakes. These changes will complicate decryption performed by all security, analytics and performance monitoring tools today.

In this blog, I define what Secure Sockets Layer (SSL)/TLS means for your infrastructure, why you should care and how to roll out centralized decryption in a practical way with a next-generation network packet broker (NGNPB). Spoiler alert: Centralizing SSL/TLS decryption is often less difficult than people think and is always rewarding at the end.

What Is SSL/TLS Encryption?

SSL/TLS encryption is the de facto standard on the web for keeping data secure end-to-end during communication for e-commerce, banking, email, search, social media, voice-over-IP, file storage and many other public-facing and internal applications. It’s a system based on certificates issued by trusted certificate authorities to identify servers and optionally clients. In recent years, SSL has evolved to the TLS standard.

Increasingly, SSL/TLS is being used more widely for cloud applications that were traditionally east-west network traffic and were easily monitored.

Driving with One (Dimming) Headlight

According to Google, 89 of the top 100 sites on the internet, representing 25 percent of worldwide internet traffic, now default to HTTPS. Yet, almost half of SecOps teams, and consequently their tools, don’t have visibility into this traffic. In addition, internal communications’ east-west traffic is being increasingly encrypted. Here’s another data point from LetsEncrypt.org: over 85 percent of web pages loaded by Firefox in the U.S. are encrypted with SSL/TLS.

Source: Let’s Encrypt/Firefox Telemetry

Encrypted traffic has become one of the biggest blind spots in an enterprise, and “we don’t see what’s going on in 80 percent of traffic coming in and out of our network” is a difficult discussion to have your boss if you’re a security professional.

Bad Guys Heart Encrypted Traffic

Unfortunately, the wide-spread adoption of encryption isn’t limited to well-meaning parties. It’s increasingly used by bad actors to disguise their actions, exploiting the very technology used to make user data and privacy more secure for their own ends.

Cybercriminals use encryption to:

  • Conceal malware
  • Hide command-and-control traffic
  • Cloak the exfiltration of stolen data

While organizations may monitor some encrypted traffic for threats, technology limitations and decentralized intelligence leave many SecOps teams with limited visibility, creating blind spots for would be actors to exploit.

Cost of Decrypt at Every Tool Approach

A wide range of security tools need traffic in the clear to function, including malware detection tools, next-gen firewalls (NGFW), web application firewalls, web security gateways, IPSs and data-loss prevention systems. To achieve this, nearly all network-based tools offer their own decryption capabilities.  

However, decryption is a processor-intensive function that consumes a large amount of resources from security tools. Below is a diagram of a typical layout for decryption in an enterprise network. You may notice several non-optimal features of this arrangement:

  • Not every tool has visibility into all the decrypted traffic it needs to inspect
  • The same traffic is decrypted and re-encrypted by several tools because the tools cannot share decrypted traffic with each other
  • Each decryption and re-encryption adds latency, which in turn slows the user experience

In a study of eight leading NGFWs, NSS Labs found that turning on SSL decryption degraded the performance of the firewalls by as much as 80 percent and reduced the connection rate by an average of 92 percent. (Source: NSS Labs Expands 2018 NGFW Group Test with SSL/TLS Security and Performance Test Reports.)

These performance degradations force SecOps teams to swallow increased tool costs to cope with traffic volume increases, or face the risk of missing potential threats and unusual behavior in their environments as tools begin to drop packets. The situation is particularly severe for interactive applications, like VoIP, multimedia and web 2.0 applications.

Implication for Analytics and Monitoring Tools

Similar considerations apply to analytics and performance monitoring tools. In many situations, encryption hides packet headers as well as payloads, making it difficult or impossible to read data about application type, source and destination addresses, ports, DNS lookups, certificates and many other types of information used to measure performance, map data flows, find anomalous behaviors and detect trends. Then there’s troubleshooting: The lack of access to unencrypted traffic will affect MTTI (Mean Time to Identify) and even systems uptime.

In fact, obtaining pervasive visibility into encrypted traffic is critical for:

  • Security analytics and user and entity behavior analytics (UEBA) tools
  • Cloud service monitoring tools
  • Network, security and application monitoring tools

Centralizing SSL/TLS Decryption in Your Infrastructure

Since a network architecture that replicates SSL/TLS decryption creates performance bottlenecks in tools, what options do security and network teams have to ensure they are accurately monitoring all traffic?

For inline tools, decryption is often used as shorthand for both decryption of network packets received from the source and re-encryption of the packets before they are sent to the destination.

A next-generation network packet broker (NGNPB) like those offered by Gigamon can create a decryption zone where SSL/TLS traffic from all TCP ports and applications is decrypted once and fed to multiple tools. In this scenario:

  • Every tool has visibility into all the decrypted traffic it can usefully inspect, increasing the accuracy of the security and analytics tools
  • The same traffic is decrypted and re-encrypted only once and that work is offloaded from the tools, which speeds up performance, reduces latency introduced by decryption and enables fewer tools to handle the same traffic
  • The diagram below illustrates these points in an inline deployment architecture, while the same concept applies in an out of band environment

Supporting Advanced Cryptographic Techniques

To successfully centralize SSL/TLS decryption, support is needed for advanced cryptographic techniques for not only RSA, but also for Diffie-Hellman Ephemeral, Elliptic Curves, AES, POLY1305/CHACHA2, and even RSA for legacy TLS 1.2 and earlier. When a NGNPB supports these techniques, enterprises can utilize the latest encryption technologies quickly without needing to upgrade every tool in the environment.

Checking for Valid Certificates

Gigamon NGNPBs can also improve your security posture by checking certificate revocation lists and by using the Online Certificate Status Protocol to determine whether encryption certificates are invalid or have been revoked by the issuing certificate authority. This helps authentication by making it more difficult for attackers to spoof legitimate web sites. Lastly, you can overlay an enterprise certificate policy, vastly improving your security posture.

Enforcing Privacy Regulations and Other Policies

The European Union’s General Data Protection Regulation (GDPR) and other privacy regulations mandate that the personally identifiable information (PII) of EU subjects must be protected. Encryption represents the best way to achieve data protection compliance within GDPR requirements.

Since Gigamon NGNPBs can selectively decrypt traffic using URL categories, IP addresses, whitelists, blacklists and other criteria, IT/legal/compliance teams can use this filtering to ensure traffic that includes PII remains encrypted and compliant with data privacy regulations.

Additionally, filtering can enforce other policies, such as encrypting all traffic that leaves the network, but not encrypting traffic that remains inside the network.

Last Word

In this blog I have illustrated the rapid adoption of SSL/TLS and explained why it’s not sufficient and grossly inefficient to burden security and analytics tools with the task of decryption/re-encryption over and over again.

We believe that with Gigamon NGNPBs you will not only avoid that problem, but also benefit from a variety of other capabilities, like traffic deduplication, inline bypass, application intelligence, metadata generation and many, many other use cases. It’s an install-once, benefit-over-and-over result as your network infrastructure continues to morph.

If all that sound beneficial, please contact us so we can show you how we can centralize SSL/TLS decryption in your organization today.


Back to top