This blog is the first in a series that looks at a NIST project “Addressing Visibility Challenges with TLS 1.3 within the Enterprise.” The home page for the project is here: https://www.nccoe.nist.gov/addressing-visibility-challenges-tls-13. The NIST site includes details of the project and organizations involved in the project as well as drafts of the project documents which will be updated as the project progresses.
Mira Security has been a participant in the project since its inception and the latest Encrypted Traffic Orchestrator (ETO) software includes support for the capabilities being developed and tested by the project.
So, what are the challenges raised by the use of TLS 1.3 with regard to visibility into TLS traffic within the enterprise? The primary issue is that TLS 1.3 enforces the use of ephemeral Diffie-Hellman key exchange in order to guarantee “Perfect Forward Secrecy” (PFS) to every TLS 1.3 session. This change prevents passive decryption of the session by a device receiving a copy of the packets and holding a copy of the TLS server’s certificate and private key. Passive TLS decryption is widely used within Enterprise data centers allowing security and troubleshooting tools to be used. While it is still possible for a network device to provide visibility into TLS 1.3 this has to be done by an in-line device performing a “break and inspect” (B&I) function. Within an enterprise data center visibility may be required at many points in the network which is not an issue if passive visibility can be used but is a major issue if an in-line device is required at every point as failure of any of the in-line devices will cause the TLS session to fail.
The Mira ETO software supports passive decryption of TLS traffic prior to TLS 1.3. So, for example a TLS 1.2 session that uses RSA key exchange mechanisms can be passively decrypted by ETO as long as it has a copy of the destination TLS server’s certificate and key. ETO can also decrypt all versions of TLS (including TLS 1.3) traffic when operating as an in-line (B&I) device. In B&I mode ETO can decrypt either by using a copy of the server certificate and key or by re-signing the server certificate using a trusted certificate authority (CA) before it is sent on to the client.
It is worth pointing out that any mechanism to gain visibility into a TLS flow requires some control over either the client or server involved in the connection. Without control over one or other end of the connection a passive or B&I device will be unable to decrypt a TLS session. TLS is a very robust and secure protocol and prevents a third party network device from intercepting and decrypting the traffic unless it has control over one or other end of the connection. The most frequent forms of control are:
Certificate re-signing can only be used by an in-line device as it involves changing the server certificate sent by the TLS server before it reaches the TLS client. This rules out the use of certificate re-signing as a way to address the TLS 1.3 visibility issue being considered in the NIST project.
The following diagrams show the mechanisms used to gain visibility into TLS traffic prior to the work being done in the NIST project and make clear that passive decryption is not possible with TLS 1.3 or when certificate re-signing is being used.
Active decrypt with known server key and also using certificate re-sign
There are two new mechanisms being investigated in the NIST project, both of which require control over the TLS server. In the enterprise data center the visibility requirement is primarily for traffic terminating on TLS servers owned by the enterprise so control over the TLS server is easily achieved. One mechanism involves the use of static Diffie-Hellman keys by the server which are changed at frequent intervals. The second mechanism involves the use of an agent on the server which can capture the ephemeral key generated as the result of a TLS handshake and then export this for use by passive decryption devices.