Protocol-Level Details of the TLS 1.3 Visibility Solution

This is the second post of a series on providing visibility of TLS 1.3 traffic in the intranet. An index to the series and related materials can be found in the TLS Traffic Visibility page.

TLS 1.3 has created a major problem for enterprise data centers. The new version of the protocol has discontinued the RSA ciphersuites, as well as the static Diffie Hellman (DH) and Elliptic Curve Diffie Hellman (ECDH) ciphersuites, leaving Ephemeral DH (DHE) and Ephemeral ECDH (ECDHE) as the only key exchange primitives based on asymmetric cryptography. These primitives provide forward secrecy, but make it impossible to inspect TLS traffic in the intranet by provisioning a middlebox with a static RSA key, as is done for earlier versions of TLS. Since traffic inspection is necessary for essential tasks such as troubleshooting, attack detection and compliance audits, enterprises cannot migrate to TLS 1.3 without a solution to this problem.

On September 25 NIST held a workshop to discuss the problem. Before the workshop I posted a quick write up on this blog proposing a solution that provides plaintext visibility of the TLS traffic while preserving the forward secrecy provided by TLS 1.3. This post explains the solution in more detail with reference to the specification of TLS 1.3 in RFC 8446, and includes security considerations and performance considerations.

Overview

As mentioned in Section 2 of the RFC, TLS 1.3 supports three key exchange modes:

key agreement using (EC)DHE;
pre-shared key (PSK); and
PSK with (EC)DHE.

In this post I explain how the visibility solution handles the (EC)DHE-only mode. It can similarly handle the combination of (EC)DHE with a pre-shared key, but I’m leaving the details of that for another post. In a future post I also plan to explain how a pre-computation optimization can eliminate the latency that the visibility solution adds to the TLS handshake.

The visibility solution uses a middlebox (the visibility middlebox) to observe the TCP connection that carries the TLS traffic. The middlebox is purely passive. It reads the traffic by metaphorically “tapping the wire” between the TLS client and the TLS server. In the early days of Ethernet technology the wire could be literally tapped using a Network Interface Card (NIC) in promiscuous mode. Today traffic on the wire is commonly monitored by mirroring a port of a switch located in the network path followed by the traffic of interest.

Port mirroring can be performed on both physical and virtual networks. AWS has a feature for mirrorring a server port, which could be used by the visibility middlebox to mirror the TLS port of the server without having to identify a switch in the client-to-server path and perhaps having to move the mirroring to a different switch if the network is reconfigured.

When a ClientHello message is received from a TLS client the visibility middlebox and the TLS server use (EC)DHE key pairs that I will call the visibility key pairs to perform a key exchange and establish a visibility shared secret. The server uses HKDF to derive an appropriate number of pseudo-random bits from the visibility shared secret, and uses those pseudo-random bits to generate its (EC)DHE key pair for the TLS key exchange (the TLS key pair); then it follows the TLS 1.3 specification to perform the TLS key exchange, establish the TLS shared secret with the client, and derive the traffic keys from the TLS shared secret. In parallel, the middlebox derives on its own the same TLS private key from the visibility shared secret, and the TLS shared secret from the TLS private key and the client’s public key, which it reads from the wire; then it derives the traffic keys and is thus able to decrypt the TLS traffic.

The Details

The TLS server communicates with the visibility middlebox through a TCP connection established over the same wire that carries the client-server traffic or over a different wire between ad-hoc network interfaces. I will refer to this connection, which may be a long-standing TCP connection between the machines, as the server-middlebox connection, and to the TCP connection that carries the TLS traffic as the client-server connection. A visibility pre-shared key is used by the middlebox and the server to compute symmetric (HMAC) signatures on the messages that they send to each other over the server-middlebox connection.

The figure below shows in more detail the steps performed by the visibility middlebox and the TLS server, and how they are interleaved with the message flow of Figure 1 of RFC 8446.

Interleaving of visibility solution steps with TLS 1.3 message flow

In the figure, horizontal dashed arrows denote messages sent on the client-server connection, while horizontal solid arrows denote messages sent on the server-middlebox connection. In the middlebox and server columns vertical solid lines denote synchronous threads of execution, while vertical dotted lines indicate waiting. When resuming computation after waiting, the middlebox and the server must retrieve the computational context of the previous thread of execution. To that purpose they each maintain a TLS connection record where they keep data such as public and private keys, shared secrets, key-schedule secrets and traffic keys. The TLS connection record is associated with the client-server TCP connection by means of a connection ID stored in the record, consisting of the IP address and TCP port of the source and the destination of the connection.

The numbers on the left of the figure refer to the following steps:

The client initiates the TLS connection by sending the ClientHello message, which the server receives and the middlebox sees on the client-server TCP connection. The middlebox and the server each creates its TLS connection record and stores the message and the connection ID in the record. The message includes a 256-bit random value and a collection of extensions, including an extension called “key_share” that contains one or more “KeyShareEntry” structures. Each “KeyShareEntry” structure has a “group” field containing the name of a group that the client proposes for the key exchange, and a “key_exchange” field containing the public key component of an (EC)DHE key pair generated by the client for that group.
The server selects a group among those proposed by the client (the TLS group), chooses a named group for the visibility key exchange (the visibility group) and generates its ephemeral visibility key pair for that group using a pseudo-random bit generator. The visibility group may or may not be the same as the TLS group, and does not even have to be one the TLS groups, as discussed below in the Security Strength subsection of the security considerations.
The server sends a message to the middlebox over the server-middlebox connection, containing the names of the TLS group and the visibility group, the visibility public key, and the connection ID. The middlebox locates the TLS connection record containing the connection ID and resumes computation.
The middlebox generates its own visibility key pair for the selected group using its own pseudo-random bit generator.
The middlebox sends a message to the server over the server-middlebox connection, containing its visibility public key and the connection ID, which the server uses to locate the TLS connection record and resume computation.
The middlebox and the server independently compute the visibility shared secret, each from its own visibility private key and the other’s visibility public key.
The middlebox and the server independently generate the TLS private key for the TLS group selected by the server, using HKDF to derive the required number of pseudo-random bits from the visibility shared secret, as described below in the Private Key Generation section. The server computes the TLS public key from the TLS private key and the parameters of the selected TLS group. The middlebox does not need to compute the TLS public key.
The server sends the ServerHello message. The middlebox sees the message on the client-server TCP connection, locates the TLS connection record associated with the connection, saves the message in the record, and resumes computation. (As specified in Section 4.1.3 of RFC 8446, the message conveys to the client the name of the selected group and the TLS public key in a “KeyShareEntry” of a “key_share” extension. The middlebox does not need this information, since it learned which group was selected in Step 3 and it does not use the TLS public key. But it needs the message because the message is included in the transcript hashes that are used in the computation of the traffic secrets.)
The middlebox and the server independently compute the TLS shared secret from the TLS private key and the public key sent by the client in the ClientHello message.
The middlebox and the server compute the client and server handshake traffic secrets and keys. They first compute the “handshake secret” from the TLS shared secret, as shown in the key schedule of Section 7.1 of RFC 8446, where the TLS shared secret is called “the (EC)DHE secret”, or just “ (EC)DHE” in the diagram of page 92. Then they compute the “client_handshake_traffic_secret” and the “server_handshake_traffic_secret” from the handshake secret, using the transcript hash of the ClientHello-ServerHello message sequence as an input. Finally they compute the handshake traffic keys from the handshake traffic secrets as specified in Section 7.3 of the RFC.
The server sends its encrypted handshake messages, protected by the server handshake traffic keys as indicated by the curly brackets in the above figure. (The “Certificate” and “CertificateVerify” messages are marked as optional by an asterisk in Figure 1 of the RFC, but they are not optional in the (EC)DHE-only case that we are considering in this post.) The middlebox sees the messages on the client-server TCP connection, locates the TLS connection record associated with the connection, saves the messages in the record, and resumes computation.
The middlebox decrypts the encrypted handshake messages sent by the server using the server handshake traffic keys, which it finds in the TLS connection record.
The middlebox and the server, independently and in parallel with the client, compute the client and server application traffic secrets and keys. They first compute the “master secret” from the handshake secret, as shown in the key schedule of Section 7.1 of RFC 8446. Then they compute the initial versions of the application traffic secrets, “client_application_traffic_secret_0” and “server_application_traffic_secret_0”, from the master secret, using as an input the transcript hash of the handshake messages up to and including the Finished message sent by the server. Notice that transcript hash is computed on plaintext messages, so the middlebox must perform Step 12 before it can perform Step 13. The initial versions of the application traffic secrets may later be updated in the course of the TLS connection as specified in Section 7.2 of the RFC. Finally the middlebox and the server compute the application traffic keys from the application traffic secrets as specified in Section 7.3.
The server may send Application Data before the optional client authentication and the Finished message of the client, protected by the server application traffic keys. If so, the middlebox sees the data on the client-server TCP connection and decrypts it using the server application traffic keys found in the TLS connection record associated with the TCP connection.
The client sends its encrypted handshake messages, protected by the client handshake traffic keys. The middlebox sees the messages on the client-server TCP connection, locates the TLS connection record associated with the connection, saves the messages in the record, and resumes computation.
The middlebox and the server decrypt the encrypted handshake messages sent by the client using the client handshake traffic keys.
The middlebox and the server, independently and in parallel with the client, compute the “resumption_master_secret” from the master secret using as an input the transcript hash of all the handshake messages, up to and including the Finished message sent by the client. I’m leaving a discussion of a possible use of the resumption master secret by the visibility middlebox for another post.
Client and server exchange application data protected by the client and server application traffic keys. The middlebox sees the data on the client-server TCP connection and decrypts it using the client and server application traffic keys. Separately, the server decrypts the client application data with its own copy of the client application traffic keys.

Private Key Generation

Section 4.2.7 of the TLS 1.3 specification lists the ten named groups that can be used for key agreement:

Five finite field groups for DHE, named ffdhe2048, ffdhe3072, ffdhe4096, ffdhe6144 and ffdhe8192; and
Five elliptic curve groups for ECDHE, named secp256r1, secp384r1, secp521r1, x25519 and x448.

In all these groups the private key is generated from random bits, which are ordinarily produced by a pseudo-random bit generator such as Hash_DRBG or HMAC_DRBG, defined in NIST SP 800-90Ar1. In the visibility solution they are instead derived using HKDF from the bits of the visibility shared secret, which are themselves pseudo-random bits that inherit their randomness from the pseudo-random bit generators used to generate the visibility private keys of the middlebox and the server. More specifically, HKDF is used with SHA-256 as the Hash parameter, which amounts to calling HMAC-SHA-256 two or more times as defined in the RFC, and the following inputs: a string of 32 zero octets as the salt input, the visibility shared secret as the IKM input, a zero-length string as the info input, and the required number of octets as the L input.

The rest of this section specifies the required number of random octets for each of the nine groups, and how they are used to generate the TLS private key.

The groups x25519 and x448 are based on the Edwards curves Ed25519 and Ed448 of RFC 8032. The required number of octets is 32 for x25519 and 56 for x448, and those octets become the private key without former manipulation.

For the other groups the private key is generated using the “Extra Random Bits” method defined in Section 5.6.1.1.3 of NIST SP 800-56Ar3 for the finite field groups and in Section 5.6.1.2.1 for the elliptic curve groups. (The alternative “Testing Candidates” method is not suitable since it would require repeated computation of the visibility shared secret.) The “Extra Random Bits” method takes as input 8 more octets (64 bits) than the size of the private key, whose purpose is to reduce the bias caused by a modular reduction used to bring the private key within its numeric range.

The groups secp256r1, secp384r1 and secp521r1 are based on the NIST curves P-256, P-384 and P-521 defined in Draft NIST SP 800-186. The private keys used in those groups range between 1 and (n – 1) inclusive, where n is the order of the base point of the curve. Their bit lengths are 256, 384 and 521, and the required numbers of octets for the “Extra Bits” method are thus 40, 56 and 74 respectively.

The finite field groups are safe-prime groups defined in RFC 7919. Section 5.6.1.1.1 of SP 800-56Ar3 does not uniquely specify the range of the private key. The private key must be greater than 0 and less than q where q = (p – 1)/2 and p is the safe prime. But q is very large, so implementers are allowed to restrict the number of bits of the private key to any number N greater than or equal to 2s, where s the security strength and 2s is much less than the bitlength of q. (See the table of security strengths in the Security Strength section below.) The same value of N must be configured into the middlebox and server so that they generate the same private key from the visibility shared secret. The required number of octets is 8 plus the ceiling of N/8 for that value of N.

Security Considerations

Forward Secrecy

The (EC)DHE key exchange of TLS 1.3 provides forward secrecy against an adversary who records the traffic between the client and the server. The traffic keys cannot be derived without knowledge of the TLS shared secret, the shared secret cannot be derived without knowledge of one of the private keys, and the private keys are derived from pseudo-random bit generators whose outputs cannot be reproduced at a later date. So as long the client and the server take care of deleting their private keys and the shared secret after the key exchange, and their instances of the traffic keys when they are updated or the connection is closed, the adversary will not be able to decrypt the traffic at a later date.

The visibility solution provides forward secrecy against an adversary who records the traffic between the client and the server, as well as the traffic between the middlebox and the server. The traffic keys cannot be derived without knowledge of the TLS shared secret and the shared secret cannot be computed without knowledge of one of the private keys. The private key of the server is derived from the visibility shared secret instead of being derived from a pseudo-random bit generator, and a copy of it is derived from the visibility shared secret by the middlebox. But the visibility shared secret, like the TLS shared secret, is established by an (EC)DHE key agreement and cannot be computed without knowledge of one of the visibility private keys, which are themselves derived from pseudo-random generators whose outputs cannot be reproduced at a later date. So as long as the client, the server and the middlebox take care of deleting their TLS private keys, the TLS shared secret and the traffic keys, and the middlebox and the server take care of deleting their visibility private keys and the visibility shared secret, the adversary will not be able to decrypt the traffic at a later date.

Security Strength

The security strength of a system that employs several cryptographic primitives is no greater than the smallest of the security strengths of those primitives. Therefore to ensure that the visibility solution does not reduce the security strength of the protection provided by a TLS connection, each primitive used in the solution must have a security strength at least equal to that of the most secure key exchange supported by the server and used in conjunction with the solution.

The table below lists the security strengths of the (EC)DHE key exchange for the groups available in TLS 1.3. Those for the finite field groups and the elliptic curve groups based on NIST curves come from Tables 26 and 24 respectively of NIST SP 800-56Ar3. Those for x25519 and x448 are the security strengths of the curves Ed25519 and Ed448 as stated at the end of the Section 1 of RFC 8032.

Security strenghts of the TLS 1.3 groups
Finite field groups		Elliptic curve groups
ffdhe2048	112	secp256r1	128
ffdhe3072	128	secp384r1	192
ffdhe4096	152	secp521r1	256
ffdhe6144	176	x25519	128
ffdhe8192	200	x448	224

The cryptographic primitives used by the visibility solution beyond those used by TLS 1.3 include :

The pseudo-random bit generators used by the middlebox and the TLS server to generate their respective visibility private keys;
The key derivation function HKDF with SHA-256 as the hash parameter used to derive random bits for the generation of the TLS private key as described above in the Private Key Generation section;
The symmetric signature primitive HMAC used to sign messages sent on the server-middlebox TCP connection; and
The key exchange primitive used to compute the visibility shared secret.

Regarding the generation of the visibility private keys, the commonly used pseudo-random bit generators Hash_DRBG and HMAC_DRBG defined in NIST SP 800-90Ar1 provide 256 bits of security strength when parameterized with SHA-256 as is usually done. Since 256 bits is the highest security strength of the (EC)DHE key exchange methods of TLS 1.3, those pseudo-random bit generators can be used in an implementation of the visibility solution without reducing the security strength of TLS.

Regarding the generation of the TLS private key, HKDF parameterized with SHA-256 also provides 256 bits of security strength and can therefore be used without reducing the security strength of TLS.

Regarding symmetric signatures, while HMAC-SHA-256 provides 256 bits of security strength when used for key derivation or random bit generation, it only provides 128 bits when used in applications that require collision resistance such as digital signature, as stated in Table 3 of NIST SP 800-57 Part 1 Revision 5. So HMAC-SHA-256 can only be used to sign the messages exchanged on the server-middlebox connection if the server supports no TLS groups other than ffdhe2048, ffdhe3072 and secp256r1. Stronger symmetric signature primitives such as HMAC-SHA-512 must be supported if any other group is supported.

Regarding key exchange, since the middlebox must support all the TLS groups that the server supports, and since the server chooses the visibility group and the TLS group at the same time, a simple way of ensuring that the visibility key exchange does not reduce the security provided by TLS is to let the two groups be the same. However, if the TLS client only supports slow groups (i.e. groups where ephemeral key generation plus key exchange takes a long time), the server may want to choose as the visibility group a faster group not supported by the client that is no less secure than the TLS group. For example, if the negotiated TLS group is the slow ffdhe8192, the server may want to choose secp521r1 or x448 as the visibility group.

Performance Considerations

As can be seen in the above figure, the visibility solution introduces the following steps that add to the latency of the TLS handshake:

Generation of the visibility key pair by the server;
Transmission of the visibility public key of the server to the middlebox over the server-middlebox TCP connection;
Generation of the visibility key pair by the client;
Transmission of the visibility public key of the client to the server over the same server-middlebox TCP connection; and
Computation of the visibility shared secret by the server.

As I will explain in another post, the three computational steps (1, 3 and 5) can be eliminated by precomputation, leaving only the two transmissions over the server-middlebox TCP connection, which should have a negligible latency cost if the middlebox and the server are located in the same subnet of an on-premise or cloud-based intranet.

Next post in this series: Extending the TLS 1.3 Visibility Solution to Include PSK and 0-RTT.

Previous post in this series: Reconciling Forward Secrecy with Network Traffic Visibility in Enterprise Deployments of TLS 1.3.