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:
- Possessing a copy of the TLS servers certificate and private key
- Being a trusted CA allowing server certificates re-signed by the device to be trusted by the TLS client
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.
Passive decrypt with known server key
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.
The next blog in this series will look at the use of Static Diffie-Hellman keys in detail.
About the Author
David Wells is a seasoned product strategist and entrepreneur with a career spanning over three decades in technology, networking and cybersecurity. Currently, he collaborates with Mira Security to deliver industry-leading encrypted traffic visibility solutions, while also running his consultancy, Glen Tech, where he advises global tech companies and supports local businesses in Ireland.
David has held prominent leadership roles, including VP of Product Management at Blue Coat Systems (later acquired by Symantec) and founder of Netronome Systems, where he contributed significantly to advancements in SSL technology and enterprise security. His expertise extends to corporate strategy, R&D, mergers and acquisitions, and technology marketing, with impactful tenures at Marconi PLC, Tellabs and Netcomm Ltd.
Now based in County Kerry, Ireland, David combines his professional expertise with personal passions like boating, blending innovation with community involvement. His career is marked by a commitment to driving technological progress and empowering both enterprises and local communities.
