How Do You Run Cryptography Faster and Stay Secure Without Tripping Over Hackers?

Updated October 28, 2021.

TLS (aka SSL) Is Old Hat for Secure Communications. Right?

Session security using SSL/TLS cryptography is well understood by SecOps and has been used for decades for both public facing and internally focused applications. This method is the norm for most organizations. Across all of Google, over 94 percent of traffic is encrypted and 96 of the top 100 non-Google sites, accounting for 25 percent of the total throughput, implement encryption by default.¹

It is the standard method used for securing end-to-end web transactions, including online banking, health care file sharing, social media, video/voice over IP (VoIP) and shopping sessions for e-commerce. Beyond these needs for confidentiality, search engine results rank secure sites much higher and thus encryption is effectively mandatory. Unfortunately, it has been known for some time that the prevailing standard, TLS 1.2, had some security and performance shortcomings — thus began the quest for TLS 1.3.

TLS 1.3 Adoption Taking Hold, but Be Mindful of Caveats

After a ten-year slugfest, this version was finally finalized in March 2018 and released in August 2018 by the IETF² and is deemed the gold standard for internet connection security. This new version has a long list of security and performance improvements and is gaining serious acceptance. Twenty-eight percent of sites now support TLS 1.3 and over 60 percent of sites support the related Forward Secrecy.³ Up to 40 percent of large enterprises have already instituted this latest incarnation.⁴

Quantum Leap in Security

TLS 1.3 is more secure than its predecessors because it deprecates the use of weak ciphers, restricts handshakes and negotiations, and obfuscates more of the encryption setup process. More specifically, the protocol requires²:

• Implementing Forward Secrecy FS). In both the RSA non-forward secret key exchange, and in forward secret key exchanges, a unique key is negotiated between client and server. However, it’s the way this is negotiated that is critical to understanding what FS means. With FS the key exchange uses the Diffie-Hellman Ephemeral protocol; the client and server each generate a random number and send values derived from that number to each other to arrive at a shared key in a way that can’t be intercepted by a passive third party. An authentication mechanism is then used to confirm that no active man-in-the-middle attack has taken place. Once those random numbers in memory are deleted, neither the client not server can regenerate the key anymore. This gives forward secrecy because there is no way to derive the session keys after those random numbers in memory have been erased. 
• Dropping the use of obsolete and insecure cipher suites.
  • The RSA key exchange algorithm (and several others) were canned from TLS 1.3 because they’re not forward secret.  The risk here is that traffic between a server and client was recorded, and at some time in the future the server’s private key was stolen, all that historical data could be decrypted. TLS 1.3 allows only forward secret key exchanges.
  • CBC mode ciphers are vulnerable to ‘BEAST’ and ‘Lucky 13’ attacks. With BEAST attackers with a privileged position in the network and the ability to trick a user into going to a malicious site can decrypt data when any of these ciphers are used.
  • The RC4 stream cipher is not secure for use in HTTPS. It is deemed to have a weak underlying algorithm, is subject to keystream bias and is susceptible to being quickly broken or retroactively decrypted. There are numerous documented attacks and best practice says IT should move away from this cipher.
  • Other ciphers banished include DES, 3DES, static/non-ephemeral DH, and Export strength (low number of bits) cipher variants.
  • Hashing algorithms banished include SHA-1 and MD5.
• Use of encryption for most of the handshake. In prior versions, many critical elements, including the Subject Alternate Name (SAN), are in cleartext and subject to eavesdropping. With TLS 1.3, all handshake exchanges between the client and server after the initial ‘client hello’ are encrypted by default. This includes the server certificate in the ‘server hello’ message. However, the Server Name Identification (SNI) remains viewable – although encrypted SNI is being evaluated and supported by some browsers, such as Mozilla Firefox.
• The elimination of negotiable cipher suite preferences. Previously, clients could renegotiate the list of ciphers by reordering the preference list in the ‘Server Hello’. In TLS 1.3, the prioritized list is called the ‘Supported Version’ and is provided when the connection is being established. For 1.2 and older versions, the list is now called the ‘Legacy Version’. Such a change prevents a ‘downgrade attack’ (known as FREAK) whereby a hacker could otherwise reorder the list and downgrade the client to a cipher more susceptible to attack.

TLS 1.2 and earlier versions were subject to misconfigurations that left websites vulnerable. TLS 1.3 is much simpler to administer and more restrictive, hence eliminating errors.

Performance Boost

The TLS 1.3 session establishment and negotiation process are significantly optimized², which:

• Expedites data transfers by using Fast Open cookies for zero round trip time (0-RTT). In this scenario, sites previously visited are cached so data can be sent even before the TLS connection is completed. When a client initially connects to a server, it inserts an empty cookie in the initial SYN message, instigating the server to reply with a valid cookie. For subsequent sessions, the client copies the cookie in the SYN message, and then transmits data immediately. If the server recognizes the data as valid, it will forward it to the application. This method leverages pre-shared keys (PSK) from established TLS connections. Note that 0-RTT restarts do not provide full forward secrecy as per section E.1.3 of RFC8446.
• Accelerates the handshake process by using False Start. With TLS 1.3 the time to authenticate the server and negotiate the cipher suites and protocol versions to be used is cut in half, typically saving 100 ms or even more for remote sites. Normally this process takes two round-trip delay times (RTT) between client and server during the initial handshake. The first RTT involves the client hello and server hello to agree on parameters and keys of the connection. The second RTT includes the verification of the TLS handshake integrity through the client and server finished messages. In TLS 1.3 this initial handshake has been cut down to one RTT.
• When you combine TCP Fast Open and TLS False Start, the key negotiation is performed simultaneously with the initial TCP handshake. There is just one RTT before the HTTPS traffic starts.

You Mentioned Caveats: Explain

Move to Inline Full Proxy Architectures

Administrators need full visibility to properly inspect encrypted traffic. Consider that over 2.8 million cyberattacks in 2018 were hidden in encrypted traffic.⁵ To identify malware, spot data exfiltration, block nefarious attempts to inject command and control code onto servers and more, SecOps use a myriad of security solutions. Similarly, NetOps folks are required to ensure constant uptime and exceed SLAs; in doing so they use application and network performance monitoring tools for troubleshooting and remediation. While they could burden these tools with the decryption processing, the performance and latency hits are egregious.

Historically, they have turned to passive, out-of-band decryption solutions that are common in many large enterprises, particularly those that have strong regulatory and compliance requirements. However, with TLS 1.3, this is no longer possible, as PFS is mandatory. Organizations will have to re-architect their infrastructure to manage security and monitoring regarding TLS 1.3 traffic. As TLS 1.3 doesn’t allow shuffling of cipher suite preference lists, pseudo-proxy decryption solutions will likely fail and result in network outages or expose users to potential attacks.

What is needed is a true active, inline, full-proxy platform. This solution implements the complete TLS stack and intercepts the client connection to the server, initiates its own client connection and sets up a separate connection to the server. Once a connection is made through this proxy, it needs to maintain the connection for the entire duration of the communication. Active proxy solutions have full control over the choice of approved cipher suites and TLS versions, can downgrade TLS 1.3 connections to TLS 1.2 if needed, or have separate TLS versions on the client and server sides.

Such man-in-the-middle devices are tailor-made to handle the TLS decryption on special hardware adapters and potentially re-encrypt at line speeds with minimal latency. Organizations can take advantage of these types of solutions to enhance their compliance and security posture.

Minimize Privacy Concerns with In-Box Decryption Bypass

Several industries, including financial services and healthcare, are subject to privacy standards. For instance, the Health Insurance Portability and Accountability Act (HIPAA) mandates that patient record confidentiality be upheld with data in motion secured via encryption. Decryption solutions as a bump-in-the-wire should not decrypt, but bypass, this traffic and send it directly to the server.

Assuming encrypted SNI (ESNI) does not become a rule, a decryption solution can allow bypass based on this client information. However, other issues arise. With TLS 1.3, the server certificate and its SAN are no longer visible; neither server identity nor self-signed certificates can be verified. Other anomaly detection and threat hunting activities are also curtailed. It is challenging to determine if a session is with a legitimate authorized source or an infectious malware sending back command and control information to a hacker.

The answer is to decrypt traffic inline, completely within a network security solution that supports full-proxy mode, and then re-encrypt before forwarding data to and from the server. Now the SNI can be matched with the certificate SAN.

Protect Against Replay Attacks

The use of Fast Open cookies and the resultant zero RTT substantially enhances the performance of TLS 1.3 with quicker connection times, faster page downloads and expedited transactions for a better overall user experience, but this comes at a cost. Resuming sessions in this way can result in vulnerabilities. The biggest risk is from replay attacks where hackers may obtain access to your session information and use it to resend requests to servers, thereby impersonating actual clients; they can proceed to place financial transactions in your stead and make payments to their own accounts.

The IETF spells out this drawback in the TLS 1.3 RFC and acknowledges there is no assurance against these zero RTT–type attacks. To some degree, the burden of security has been shifted away from the TLS protocol to your applications, which need anti-replay defenses. A simpler preventative approach is to timestamp all messages. This limits hackers from resending messages that exceed a specified timeframe. The window of susceptibility for an attacker to snoop and siphon the message is greatly diminished.

Gigamon to the Rescue

Gigamon GigaVUE^® HC Series Visibility Appliances are next-generation network packet brokers. They can be deployed as full-proxy solutions that address these challenges introduced by TLS 1.3, while making the network more resilient and future-proof. They provide a multitude of capabilities, including physical network fail-safety, elimination of encrypted blind spots from your security and monitoring tools, inline security tool health validation, duplicate and superfluous data removal, application identification, L2–L4 flow data and advanced L3–L7 metadata generation, and much more. They do the heavy lifting, including full TLS 1.3 processing, to:

• Remove this computationally intensive task from your inline tools, allowing them to be more efficient and accurate
• Decrypt once and send to many inline tools, minimizing cumulative latency of inline security chains or stacks
• Decrypt and send copies to tools, allowing out-of-band performance and security monitoring tools visibility into applications

If you would like to learn more, contact us so we can show you how we can centralize SSL/TLS decryption in your organization today.

---

References

1. Google Transparency Report. 2020. Google. Accessed April 7, 2020. https://transparencyreport.google.com/https/overview?hl=en.
2. “The Transport Layer Security (TLS) Protocol Version 1.3.” Internet Engineering Task Force, August 2018. https://tools.ietf.org/html/rfc8446.
3. SSL Pulse. 2020. Qualys SSL Labs – SSL Pulse. Accessed April 7, 2020. https://www.ssllabs.com/ssl-pulse/.
4. Paula Musich. Report Summary: TLS 1.3 Adoption in the Enterprise. January 2019. Enterprise Management Associates Research. Accessed April 7, 2020. https://assets.extrahop.com/whitepapers/EMA-ExtraHop-TLS13-2019-RR-SUMMARY.pdf.
5. 2019 SonicWall Cyber Threat Report. 2019. SonicWall. Accessed April 7, 2020. https://www.connection.com/~/media/pdfs/brands/s/sonicwall/895739-sonicwall-cyber-threat-report-2019.pdf?la=en.