Rethinking network and security monitoring in the age of TLS 1.3

The adoption of the Transport Layer Security (TLS) 1.3 creates a watershed moment for cybersecurity, revolutionizing encryption and data protection standards. TLS has been widely used to secure data end-to-end for many decades. Though this latest version significantly enhances the security of the TLS protocol, it also severely limits the decryption of those data streams for cybersecurity and network monitoring purposes. This results in our current forms of network and security monitoring used with previous TLS versions to lose their effectiveness. The new TLS encrypted traffic actually can increase security risks by obscuring malware and traffic by threat actors as well, and therefore requires a fundamental rethinking of today’s monitoring approach.

A U.S. response to a global challenge

These changes are considered enough of a cybersecurity challenge that the U.S. National Cybersecurity Center of Excellence (NCCoE), a part of the National Institute of Standards and Technology (NIST), has started a project to “provide system and application administrators with practical tools and approaches to help them gain visibility into the traffic flowing across their networks, and to fully adopt TLS 1.3.” 

Collaborating with experts from various industries, NCCoE recently released draft publications describing the challenges of TLS 1.3 to cybersecurity and suggesting various solutions and their benefits to tackle this visibility challenge in the latest “NIST SPECIAL PUBLICATION 1800-37B: Addressing Visibility Challenges with TLS 1.3 within the Enterprise.” 

TLS 1.3 — Innovation in encryption that negatively impacts visibility 

Security, network and application operations have always relied on visibility into the traffic traversing the network, whether to determine the most efficient routing based on the data content, to measure network and application performance or to determine legitimate versus illegitimate resource usage. While ever more complex encryption and cypher technologies are employed to protect privacy and information confidentiality, it decreases visibility and increases complexity for these monitoring applications. 

The Internet Engineering Task Force (IETF) released the TLS 1.3 specification in RFC 8446 in August of 2018 and is now the most common version in use. It significantly enhanced previous TLS and SSL encryption protocols but impacts visibility and monitoring capabilities:

• TLS 1.3 has fewer handshake messages to initiate the connection between devices, which are also encrypted. This accelerates the setup process but also limits the information visible to security devices that do not carry out decryption.
• TLS 1.3 reduces the number of options and cipher suites to those that have been proven to be unbreakable so far, creating more secure communication.
• TLS 1.3 requires only cipher suites that provide Perfect Forward Secrecy (PFS) which applies cryptographic keys only to a single communication session, not all traffic sent from a device. This addresses the issue of threat actors potentially obtaining the private encryption keys to read all communication to a device, past and future. 

How is this impacting the approach today? 

Previous versions of TLS allowed for passive monitoring of the initial encryption handshake, providing vital insight. Furthermore, traffic could be decrypted if the monitoring application had a copy of each device’s static cryptographic key which then would allow for the monitoring of all traffic from these devices, whether recorded or real-time. 

TLS 1.3 on the other hand requires that any application monitoring the traffic now needs to be inline and actively involved during each TLS connection establishment. Given the number of monitoring applications utilizing network traffic, this creates a significant number of decryption points that increase risk but also can impact the performance of the traffic. An alternative approach is the distribution of each session’s cryptographic keys to each monitoring application, a process that would create millions of keys that would need to be safely managed and applied. 

NIST addressing the challenge in the enterprise

NIST assembled experts including cryptographers, network security technology providers and user organizations to identify solutions to address those issues. They focused on solutions for enterprise data centers either hosted by the enterprise (on-prem or virtual) or hosted by a third-party, public cloud provider. They did not address communication over the public Internet or for newly emerging encrypted Domain Name System (DNS) protocols. 

Each solution had to ensure that it “does not change or replace the IETF RFC 8446 standard, provides secure management of servers’ cryptographic keys, securely manages recorded traffic, and manages expectations of privacy.” The experts identified two fundamentally different approaches:

1. Passive network traffic analysis, requiring the safe storage and distribution of encryption keys to the monitoring applications.
2. Inline traffic analysis, using “middle boxes” that are inline with the traffic flow and actively participate in the encryption. This is sometimes also referred to as “break and inspect”.

Alternative approaches such as analyzing only the encrypted network traffic or using security protocols without forward secrecy are not discussed. Those approaches do not deliver on the goal of TLS 1.3 visibility and do not address the vulnerabilities to which previous TLS versions are susceptible. 

Visibility into TLS 1.3 encryption — Passive traffic analysis

The first approach is for passive traffic inspection, meaning analyzing copies of the traffic passing through the network, either in real-time or for later analysis. This requires key-management solutions that store those keys and defer deletion until the traffic inspection can be concluded. However, during this time, Perfect Forwarding Secrecy (PFS) could be compromised if threat actors would get access to those keys. This key management can be achieved in two ways:

1. A key management system provides known, fixed keys for encryption to each endpoint that is valid for a limited time and then refreshed. 
2. The organization collects encryption keys directly from the end-devices and retains those.

In this approach, key management solutions need to securely store and reliably delete those keys by policy or when they are no longer required. Furthermore, applications monitoring the traffic need to be authorized and require safe — i.e., encrypted communication mechanisms — to obtain the keys for the key management system. 

Visibility into TLS 1.3 encryption — Break and inspect via middle boxes

A middle box, whether virtual or physical, actively engages in the communication between two endpoints. It connects inline and actively participates in the communication between devices. In this context, its role is to decrypt traffic for numerous monitoring applications, thereby eliminating the need for each application to individually intercept the traffic.  Applying this approach for each monitoring application individually would create a large number of concatenated monitoring points which could degrade transfer performance and generate additional potential security vulnerabilities. Therefore, this approach should be applied at strategic points in the network and one monitoring point utilized for as many monitoring applications as possible.  

As organizations plan to enable TLS 1.3, they need to augment their traffic monitoring approach for security and all the other applications benefiting from traffic analysis.  Without this change, they will enhance data privacy while losing vital visibility into existing and emerging threats, increasing their security risks.