3 Factors to Consider When Adopting TLS 1.3 Network Encryption

The vast majority of web traffic – nearly 90% as of the end of 2019 – is encrypted to protect the information inside from malicious actors during transit. Transport Layer Security (TLS) is nearly synonymous with this process, and it forms one of the most important and widely used security protocols today. However, as TLS has evolved to adapt to new forms of interception and decryption that threaten the integrity of the information shared, not every company has kept up.    

Notably, TLS 1.3 was introduced a few years ago to speed up the handshake process and harden the security of encrypted connections with Perfect Forward Secrecy (PFS), which generates a new set of security keys for each connection. PFS makes breaching a given encryption key much more difficult by significantly shortening their lifecycle and limiting visibility in the event of a breach, but it also dramatically complicates the task of decrypting traffic for service analysis and security.

Without the right decryption technology, TLS 1.3 effectively blinds passive networks analysis appliances such as those used for performance monitoring, intrusion detection systems (IDS), and data loss prevention (DLP), which were previously decryptable using static keys. As a result, companies have had to make a difficult choice between maintaining network visibility or adopting the best encryption available, and many network teams delayed adoption of TLS 1.3 until a new generation of decryption technologies capable of handling this challenge became available.

Fast forward to today, and TLS 1.3 is quickly becoming the de facto standard for enterprises. As a result, vendors have rolled out both hardware and software solutions to manage the increased encryption complexity of TLS 1.3. Most next-gen firewalls can perform decryption, for example, but as with many other appliances, when decryption is enabled, their performance can drop significantly.

This means enterprises still considering the switch must still consider several factors before upgrading to TLS 1.3, including:

Scaling for max network demands and managing various SSL/TLS versions

Delivering speedy encryption and decryption of network traffic is essential to ensuring a positive end-user experience. But as network demands grow, so does the need for computing resources. Unfortunately, many solutions do not scale well and become cost-prohibitive for enterprise-wide security monitoring, resulting in security blind spots. To ensure a positive experience, seek out solutions that operate at line rate across a broad set of cipher suites, supporting both TLS 1.0-1.3 and SSL 3.0, with linear scaling architecture. This may include a mix of hardware and software solutions and decryption policy rules that allow network administrators to define the traffic to decrypt or exclude from decryption. 

Failover mechanisms to ensure network connectivity

Network security systems are usually deployed in either passive (out-of-band) or active (inline) mode. Regardless, it is imperative that decryption solutions are highly available to ensure continuous security monitoring and uninterrupted network connectivity, but especially for inline deployments where any failure will disrupt network connectivity. Inline security tools may also become inoperable or slow down due to traffic load -- resulting in network connectivity outages or performance degradation. Therefore, network encryption solutions need to offer high availability, with fail-safe mechanisms and bypass capabilities to meet expected performance requirements.

Security without compromising network performance

Enterprises implementing TLS 1.3 need to consider how network performance will change as security monitoring tools are added to the network, specifically with a view towards limiting the introduction of latency. In general, having multiple inline security solutions should be avoided in favor of having one device or software solution send clear traffic to security monitoring tools after decrypting just once. In addition, network engineers can check latency at the application level and set up triggers, such as routing around the tool or failing over to a redundant tool, to ensure that security does not become a bottleneck or a single point of failure.

Taking these recommendations together, organizations moving to TLS 1.3 no longer have to settle for diminished network visibility in the name of security. However, not all solutions are engineered the same, and it’s vital to implement an architecture that provides broad cipher support, scales as network traffic increases, is engineered with failsafes in place, and most importantly, leaves no blind spots concerning security.

Danny Lobo is VP of Engineering at NETSCOUT.