A Two-Version Visibility Solution for TLS 1.2 and TLS 1.3 based on a Handshake-Agnostic Middlebox

This is the fourth 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.

In earlier posts I have proposed a solution for the intranet visibility problem of TLS 1.3 based on the establishment of a visibility shared secret (VSS) between the TLS server and a visibility middlebox, using a long term TCP connection on the same or a different wire than the TLS connection. The visibility middlebox does not relay the TLS traffic: it uses port mirroring to observe the traffic, decrypts it (or, using TLS 1.3 terminology, deprotects it), and forwards the plaintext to a monitoring facility. The solution has a secret derivation (SD) variant where the middlebox derives the TLS 1.3 traffic secrets on its own, and a secret transmission (ST) variant where the server sends the traffic secrets to the middlebox encrypted under keys derived from VSS.

But a server that upgrades to TLS 1.3 must continue to support clients that use earlier versions of TLS. TLS 1.0 and TLS 1.1 have been deprecated, but TLS 1.2 may remain in use for many years. In this post I introduce a third variant that provides visibility for TLS 1.2 in addition to TLS 1.3. This two-version (2V) variant uses a handshake-agnostic visibility middlebox to handle all the key exchange modes of both versions of TLS, and preserves forward secrecy for those modes that provide it. At the end of this post I also describe a VSS precomputation feature, usable in all three variants, that I have mentioned in earlier posts but not discussed in detail yet.

Interoperability between the Middlebox and the Server

For ease of reference it may be useful to enumerate the shared parameters used for interoperability between the middlebox and the server, some of which are applicable to all three variants and have already been discussed in the earlier posts. There are connection-specific parameters, and configurable parameters that may be agreed upon by configuration of the two machines, or, preferably, by following an interoperability standard for TLS visibility that I hope will eventually come into existence.

The configurable parameters include:

• A visibility group, which, for convenience, may be one of the 10 groups defined by TLS 1.3.
• A visibility cipher suite, which, again for convenience, may be one of the 5 cipher suites defined by TLS 1.3. The visibility cipher suite specifies a visibility AEAD algorithm used to protect messages from the server to the middlebox, and a visibility hash function used for HMAC signatures and HKDF key or parameter derivations.
• The values of the “info” parameter of the “Expand” step of HKDF used for specific purposes.
• The values of protection cipher IDs used to refer to AEAD algorithms as well as to composite ciphers that combine an encryption algorithm with a message authentication method.

The connection-specific parameters include:

• The connection ID of the TCP connection over which the TLS connection is being established.
• The visibility shared secret (VSS) established in the visibility group between the middlebox and the server by performing an (EC)DHE key exchange using ephemeral visibility key pairs. To avoid confusion between the VSS and secret shared between TLS client and server, which is called “the (EC)DHE shared secret” in RFC 8446, I will refer to the latter as the TLS shared secret.
• A visibility shared key provisioned to the middlebox and the server, used to compute HMAC signatures for authenticating messages between the middlebox and the server that do not require confidentiality protection.
• A visibility AEAD key derived from the VSS and used with the visibility AEAD algorithm to protect messages from the server to the middlebox that require confidentiality protection.
• Visibility nonces used in conjunction with the visibility AEAD key, which, in the ST variant, are derived from the VSS for the protection of a fixed number of traffic secrets, and, in the 2V variant, are derived from a visibility IV for the protection of an indefinite number of protection states.

A Handshake-Agnostic Middlebox

In the SD and ST variants of the visibility solution the middlebox parses the TLS 1.3 handshake, observing the TLS records on the wire, deprotecting those that are encrypted, and recovering and interpreting the handshake messages that have been fragmented across records or coalesced into a single record.

In the 2V variant, the server provides the middlebox with all the information needed to deprotect the traffic, so that the middlebox can be handshake-agnostic: it does not have to parse the handshake and understand the semantics of the handshake messages to determine the keys and algorithms to use for deprotection. The 2V middlebox is concerned with records rather than messages, like the TLS record layer. Since the record layer is the same in TLS 1.2 and TLS 1.3, the 2V middlebox can support all the key exchange modes of both versions of TLS, and should be able to support future versions of TLS that do not change the record layer.

Plaintext records have the same content types in TLS 1.2 and TLS 1.3: “handshake”, “application_data”, “change_cipher_spec” or “alert”. The “change_cipher_spec” content type is deprecated in TLS 1.3, but may be used for compatibility with misbehaving middleboxes. Protected (or, synonymously, encrypted) records have content type “application_data”, and all plaintext records of content type “application_data” are sent protected on the wire. Therefore records observed on the wire are protected if and only if they have content type “application_data”. The middlebox deprotects those records and views the plaintext records resulting from deprotection or encountered on the wire as having opaque content.

Deprotection Processes

The work of deprotecting encrypted records and forwarding plaintext records to the monitoring facility is done by two deprotection processes, one for each direction of traffic: the client-originated traffic deprotection process (COT DP) and the server-originated traffic deprotection process (SOT DP). The middlebox creates the deprotection processes when the client establishes a TCP connection to a server port that requires TLS or the middlebox determines that traffic on an existing TCP connection will start carrying TLS records (as in StartTLS); it then pipes all TLS records for each direction of traffic to the corresponding process.

If a middlebox is observing multiple TCP connections carrying TLS records simultaneously, a separate pair of COT and SOT DPs is used for each connection. A connection ID consisting of the IP address and TCP port of the source and destination is used to identify each connection in messages between the middlebox and the server.

Protection States

To deprotect records, a deprotection process needs information on how the records have been protected. I will refer to that information as the protection state of the records.

The concept of a protection state is similar to the concept of a connection state in TLS 1.2, but with one significant difference. A connection state allows the record layer to derive the cryptographic parameters needed to deprotect traffic, but the key calculation involved in the derivation is specific to version 1.2 of TLS. By contrast, in the 2V variant a protection state includes the keys resulting from the calculation rather than the inputs to the calculation. That makes the concept of protection state generic and applicable to both versions of the protocol.

TLS 1.3 protects traffic using AEAD algorithms, which provide both confidentiality and message authentication. AEAD is also used today in TLS 1.2, but the original cipher suites in Appendix A.5 of RFC 5246 protected traffic using an encryption cipher to provide confidentiality and HMAC to provide message authentication (with the authentication code computed before encryption, a bad idea that has been the root cause of several vulnerabilities). I will use the term protection cipher to refer to an AEAD algorithm as well as to the combination of HMAC and an encryption algorithm, calling the latter a composite cipher and the former a monolithic cipher.

A protection state specifies a protection cipher using a protection cipher ID (PC ID) and the keying material to be used with the cipher.

When the protection state specifies one of the composite ciphers used in TLS 1.2, the keying material consists of the client or server write key and the client or server write MAC that are part of the key_block.

When the protection state specifies an AEAD algorithm used in TLS 1.2 or TLS 1.3, the keying material consists of a client or server write key, plus a client or server write IV that is used to generate the per-record nonces. Section 5.3 of RFC 8446 specifies a nonce generation method for TLS 1.3, where the nonces are implicit. On the other hand, Section 6.2.3.3 of RFC 5246 leaves the method of nonce generation in TLS 1.2 up to each cipher suite and suggests the use of partially explicit nonces. To accommodate this variability, a PC ID that designates an AEAD algorithm also designates a particular method of nonce generation. Different PC IDs may thus be used to refer the same algorithm when the algorithm is used in TLS 1.2 and TLS 1.3.

Secure Transmission of the Protection States

Each protection state is sent to the middlebox over the long term TCP connection between the server and the middlebox, in a message protected by the visibility AEAD algorithm under a visibility AEAD key used in conjunction with a visibility nonce. The associated data portion of the protected message includes a connection ID that identifies the TCP connection between the client and the server, and an indication of the direction of traffic as either COT or SOT. This allows the middlebox to pass the message to the appropriate deprotection process.

While in the ST variant a fixed number of visibility nonces are derived from the VSS, in the 2V variant two visibility IVs are derived from the VSS, one for each direction of traffic, and an indefinite number of nonces may be computed from each of them. This accommodates the key update feature of TLS 1.3, which may require an indefinite number of protection states per direction of traffic for application data.

The middlebox passes the VSS to each of the deprotection processes. For each direction of traffic, the server and the corresponding deprotection process separately derive a shared visibility AEAD key and a shared visibility IV from the VSS using HKDF parameterized by the visibility hash function. The per-message nonces are generated from the IVs using a message counter for each direction of traffic, in the same manner as the per-record nonces are generated using a record counter in TLS 1.3 per Section 5.3 of RFC 8446.

Protection State Sequencing

The server sends the protection states for each direction of traffic to the corresponding deprotection process as they become available and in the order in which they are to be used. The protection process encounters plaintext texts initially, and forwards them without any processing to the monitoring facility. Eventually it encounters a protected record and starts deprotecting records using the first protection state in the sequence of states that it receives from the server.

In TLS 1.2 the sequence of protection states has only one state for each direction of traffic, for the records that encapsulate the Finished process and the application data that follows. But in TLS 1.3 there are multiple protection states, so the deprotection process needs to know when to transition from one protection state to the next, without knowing how the handshake is progressing and what messages are encapsulated in the records that it is deprotecting. The deprotection process solves this problem by deprotecting records using a protection state until deprotection fails, then transitioning to the next protection state in the sequence. This sequencing method is similar to the method for rejecting early data without sending a HelloRetryRequest message, described in Section 4.2.10 of RFC 8446, in which early data is skipped by discarding records that fail deprotection.

In TLS 1.3 it is possible for the deprotection process to encounter plaintext records after protected records. Specifically, this happens for client-originated traffic when the client sends early data, then sends a second ClientHello in response to a HelloRetryRequest. The deprotection process deals with this situation by forwarding the plaintext records to the monitoring facility, then continuing to attempt deprotection of encrypted records using the same protection state that it was using before encountering the plaintext records.

Message Flows

The figures in this section show the messages transmitted over the long term TCP connection between the server and the middlebox, interleaved with each of the client-server message flows of TLS 1.2 and TLS 1.3.

In all the figures, the server and the middlebox begin by exchanging two messages to agree on a precomputed visibility shared secret, as explained in more detail in the VSS precomputation section. These messages are not encrypted, but they are authenticated by HMAC signatures computed with the provisioned visibility shared key.

The agreed upon VSS is passed by the middlebox to the two deprotection processes, allowing the server to derive a shared key and a shared IV with each of them for protecting the messages that convey the protection states. Each of those messages is depicted with the plaintext enclosed in angle brackets and an arrow labeled by the associated data, which consists of the connection ID and the direction of traffic (COT or SOT) and thus identifies the deprotection process.

In each figure the messages exchanged between the server and the middlebox are shown interleaved with those exchanged between the client and the server. However, since the two kinds of messages are sent on different TCP connections and possibly on different wires, and since the messages that convey the protection states are not acknowledged, the shown interleaving is only illustrative. The only constraints on the interleaving are that the server can only send a message after the data that determines the protection state conveyed by the message has become available to the server, and that the protection states for each direction of traffic have to be sent in the order in which they will be used by the deprotection process for that direction of traffic.

Full handshake of TLS 1.2. Figure 1 shows the messages exchanged between the server and the middlebox during the full handshake of TLS 1.2 illustrated in Figure 1 of RFC 5246.

In TLS 1.2 there are only two protection states, one for each direction of traffic. The server sends two messages conveying those protection states, one to each of the deprotection processes.

The first protection state is sent to the COT DP and includes a PC ID and client write keys. The PC ID refers to the protection cipher specified by the cipher suite that the server has selected from those offered by the client as indicated in the ServerHello message. If the protection cipher is an AEAD algorithm, the client write keys are the client_write_key and client_write_IV elements of the key block, which the server computes from the master secret and the client and server random values using a PRF specified by the cipher suite. If the protection cipher is a composite cipher, the client write keys are the client_write_MAC_key an the client_write_key elements of the key block.

The second protection state is sent to the SOT DP. It includes the same PC ID, and server write keys that are the server-side counterparts of the client write keys in the key block.

The server can send the protection states at any time after receiving the ClientKeyExchange message, which allows it to compute the master secret. The client begins sending protected records when it sends the Finished message. Since the Finished message is in the same flight as the ClientKeyExchange message, the server may not have sent the first protection state yet at that time, or the message may have been sent but not received and delivered to the COT DP. The COT DP may therefore have to wait until the first protection state becomes available.

Abbreviated handshake of TLS 1.2. Figure 2 shows the messages exchanged between the server and the middlebox during the abbreviated handshake of TLS 1.2 illustrated in Figure 2 of RFC 5246.

The abbreviated handshake is used to resume a session with the same security parameters as an original session identified by a Session ID proposed by the client in the ClientHello message. The server is able to resume the session if it has saved its security parameters. If so it can send the protection states for both directions of traffic to the middlebox before it sends the ServerHello message to the client, allowing the COT and SOT DPs to start deprotecting traffic without wait.

TLS 1.3 with no retry or early data. Figure 3 shows the messages exchanged between the server and the middlebox in a TLS 1.3 connection with no retry and no early data, established by the “basic full handshake” of Figure 1 of RFC 8446.

The server-originated traffic of a TLS 1.3 connection with no retry and no early data consists of plaintext records carrying fragments of the ServerHello message, followed by protected records carrying fragments of the encrypted handshake messages, followed by protected records carrying application data. In the absence of early data, the client-originated traffic similarly consists of plaintext records carrying fragments of the ClientHello message, followed by protected records carrying fragments of encrypted handshake messages, followed by protected records carrying application data.

Therefore the sequence of protection states for either direction of traffic consists of a protection state for the encrypted handshake traffic followed by one or more protection states for the application traffic.

The client and the server may update their application write keys at any time after sending their Finished messages, using a KeyUpdate message to notify the other party. The figure shows a KeyUpdate message message sent by the client followed by a KeyUpdate message sent by server some time later, but there may be any number of updates by the client and/or the server in any order.

As shown in the figure, the protection states for the client or server-originated encrypted handshake traffic consist of a protection cipher ID, and handshake client or server write keys respectively. The protection cipher ID refers to the AEAD algorithm specified by the cipher suite selected by the server from the those proposed by the client. The write keys consist of a client_write_key and a client_write_iv for client-originated traffic and a server_write_key and a server_write_iv for server-originated traffic, derived from the client_handshake_traffic_secret and the server_handshake_traffic_secret respectively as specified in Section 7.3 of RFC 8446. The handshake traffic secrets are derived from the PSK and/or the TLS shared secret, and from a transcript hash of the ClientHello and ServerHello messages, as specified in the key schedule. All derivations are performed using HDKF parameterized by the hash function specified by the selected cipher suite.

The server computes the handshake server write keys for its own use, and includes them in the protection state for server-originated encrypted handshake traffic that it sends to the middlebox for use by the SOT DP. The server does not have to compute the handshake client write keys for its own use, but it computes them in the same way as the handshake server write keys and includes them in the protection state for client-originated encrypted handshake traffic that it sends to the middlebox for use by the COT DP.

The server similarly constructs the initial protection states for the client and server-originated application traffic, consisting of the same protection cipher ID included in the protection states for handshake traffic, and client and server write keys derived from the initial application traffic secrets, called client_application_traffic_secret_0 and server_application_traffic_secret_0 respectively. The initial application traffic secrets are derived from the PSK and/or the TLS shared secret, and from a transcript hash of the handshake messages up to and including the server’s Finished message.

Subsequent protection states for application traffic consist of the same protection cipher ID, and application write keys derived from updated application traffic secrets, computed as described in Section 7.2 of RFC 8446.

The figure shows the protection states for the encrypted handshake traffic being sent after the ServerHello message, and those for the initial application traffic being sent after the server’s Finished message. But the server has all the information needed to construct those protected states after it receives the ClientHello message, so it could send them earlier if desired.

TLS 1.3 with retry and no early data. Figure 4 shows the messages exchanged between the server and the middlebox in a TLS 1.3 connection with retry and no early data, established by the “full handshake with mismatched parameters” of Figure 2 of RFC 8446.

The server sends the HelloRetryRequest message if the client has included a group that the server likes in the supported_groups extension of the ClientHello message, but has not included a public key for that group in the key_share extension. The server asks for the public key in the HelloRetryRequest message, the client sends it in a second ClientHello, and the server sends its own public key to the client in the ServerHello message.

In this scenario the initial plaintext records of the client-originated traffic carry the fragments of the two ClientHello messages, and those of the server-originated traffic carry the fragments of the HelloRetryRequest and ServerHello messages. However, since the middlebox is concerned with records rather than messages, there is no difference for the middlebox between the scenarios of Figure 3 and Figure 4.

TLS 1.3 with early data rejected by retry. Figure 5 shows the messages exchanged between the server and the middlebox in a TLS 1.3 connection with early data rejected by a retry. There is no figure illustrating this scenario in RFC 8446.

The client announces that it will send early data by including an early_data extension in the ClientHello message, and starts sending the early data without waiting for a server response. If the server responds to the ClientHello message with a HelloRetryRequest message, as it does in Figure 5, the client sends a second ClientHello message without the early_data extension, after having sent some prefix of the early data.

The early data is protected using an early protection cipher and early client write keys, both determined by the first PSK listed in the pre_shared_key extension of the ClientHello message and a cipher suite associated with the PSK. The early protection cipher is the one specified by the cipher suite. The early client write keys consist of a client_write_key and a client_write_iv derived from the client_early_traffic_secret as described in Section 7.3 of RFC 8446, which itself is derived from the PSK and the transcript hash of the ClientHello message as described in the key schedule, with derivations performed using HKDF parameterized by the hash function specified by the cipher suite.

The server discards the early data prefix without deprotecting it, but sends a protection state to the middlebox so that the COT DP can deprotect it and forward the resulting plaintext records to the monitoring facility. As shown in the figure, the protection state consists of an early PC ID that identifies the early protection cipher, and the early client write keys. The early protection cipher may be different from the protection cipher used for handshake and application data, identified by a late PC ID, because the client may propose multiple cipher suites in the ClientHello message and the server is free to choose a cipher suite other than the one used to protect the early data if it does not accept the early data.

In the scenario of Figure 5, the client-originated traffic consists of plaintext records carrying fragments of the first ClientHello message, followed by protected records carrying early data, followed by plaintext records carrying fragments of the second ClientHello message, followed by protected records carrying fragments of the encrypted handshake messages, followed by protected records carrying application data. The deprotection process forwards plaintext records to the monitoring facility until it finds a record with content type “application_data”; then it deprotects and forwards records using the protection state for early data until it finds a plaintext record; then it again forwards plaintext records until it finds a record with content type “application_data”; then it deprotects and forwards records using the protection state for client-originated encrypted handshake traffic and one or more protection states for client-originated application data, transitioning from one protection state to the next when deprotection fails.

TLS 1.3 with early data rejected without retry. Figure 6 shows the messages exchanged between the server and the middlebox in a TLS 1.3 connection with early data that the server rejects without requesting a retry. There is no figure illustrating this scenario in RFC 8446.

In the scenario of Figure 6 the server does not send a HelloRetryRequest message, but rejects the early data by not including an early_data extension in the EncryptedExtensions message that follows the ServerHello message. The early data is protected using an early protection cipher and early client write keys as in Figure 5, and the server sends a protection state to the middlebox that the COT DP uses to deprotect the early data.

The early data prefix sent by client is followed by records protected under the handshake client write keys, rather than by plaintext records as in Figure 5. The server skips the early data prefix that it receives from the client by discarding records that fail deprotection. The COT DP does, so-to-speak, the opposite, deprotecting early data records until deprotection fails.

TLS 1.3 with accepted early data. Figure 7 shows the messages exchanged between the server and the middlebox in a TLS 1.3 connection with early data that is accepted by the server, as illustrated in Figure 4 of RFC 8446.

The server accepts the early data by including an early_data extension in the EncryptedExtensions message that follows the ServerHello message. Section 4.2.10 of RFC 8446 stipulates that it must also accept the first PSK proposed by the client and the cipher suite associated with that PSK. This means that the same protection cipher is used to protect the early data and the handshake and application traffic, so there is no distinction between an early PC Id and late PC ID in the figure. It also means that client and server rely on their knowledge of the PSK for authentication and certificates are not used.

After seeing the server’s early_data extension, the client appends an EndOfEarlyData message to the early data protected under the same early client write keys. The server deprotects the encrypted records that encapsulate the early data using the early client write keys until it sees the EndOfEarlyData message, then transitions to using the handshake client write keys.

However there is no reason for the COT DP to use the same method as the server for transitioning from the early data protection state to the protection state that follows it, which would require knowing that the server has accepted the early data and recognizing the EndOfEarlyData message. The COT DP can simply transition when deprotection fails. There is thus no difference for the middlebox between the scenario of Figure 7, where the server accepts the early data, and the scenario of Figure 6, where it rejects it without retry.

Precomputation of the Visibility Shared Secret

All three variants of the visibility solution, SD, ST and 2V, may increase the latency of the TLS handshake because the server has to generate an ephemeral visibility key pair, perform an (EC)DHE key exchange with the middlebox, and compute the VSS. This latency cost can be eliminated by precomputing the VSS.

In the 2V variant described above, or the ST variant described in the previous post, the server also has to protect messages that it sends to the middlebox, but that latency cost should be negligible when compared to the latency of a TLS 1.2 handshake, or a TLS 1.3 handshake in (EC)DHE or PSK + (EC)DHE mode. It may even negligible when compared to the latency of a TLS 1.3 handshake in PSK-only mode, which omits the (EC)DHE key exchange but still requires 15 or more HMAC computations, transcript hashing of the handshake messages, encryption of some of the handshake messages, and a client-server roundtrip. Therefore precomputation of the VSS may eliminate all significant latency costs in all three variants (SD, ST and 2V) of the visibility solution.

Figure 8 shows the process used by the middlebox and the server for precomputing the VSS at a time when the server is idle, and agreeing on the use of a precomputed VSS at a later time when a ClientHello message is received by the server.

The VSS is computed by means of an (EC)DHE key exchange, using an (EC)DHE visibility group that provides sufficient strength against an adversary who can mount a man-in-the-middle attack between the middlebox and the server. The visibility group may be one of the TLS 1.3 groups supported by the server, such as secp521r1, which provides the highest strength of the TLS 1.3 groups listed in Section 4.2.7 of RFC 8446, as shown in the table of security strengths provided in the second post of this series.

The process comprises the following steps, numbered on the left of the figure:

1. The server generates an ephemeral visibility key pair for the visibility group.
2. The server sends the visibility public key component of the visibility key pair to the middlebox over the long term TCP connection between the server and the middlebox, in a message authenticated by an HMAC signature computed with the visibility shared key.
3. The middlebox generates its own ephemeral visibility key pair for the visibility group.
4. The middlebox sends its visibility public key to the server over the long term TCP connection, authenticated by an HMAC signature computed with the visibility shared key.
5. The middlebox and the server independently compute the VSS , each from its own visibility private key and the visibility public key of the other party.
6. The middlebox and the server independently use HKDF parameterized by the visibility hash function to derive two keys from the VSS: a key that is used to identify the VSS when one of the parties proposes its use to the other, called the VSS proposal key, and a key that is used to confirm that the other party knows the VSS, called the VSS confirmation key. Each party associates these keys with the VSS.
7. Upon receiving a ClientHello message, the server chooses one of the precomputed visibility shared secrets and sends a message to the middlebox authenticated with an HMAC signature computed with the visibility shared key containing the VSS proposal key stored with the secret, along with the connection ID that identifies the TCP connection over which the ClientHello message has been sent.
8. The middlebox uses the VSS proposal key to look for the associated VSS. If it finds the VSS, it sends the associated VSS confirmation key to the server, along with the connection ID received from the server, in a message authenticated with an HMAC signature computed with the visibility shared key. If the middlebox cannot find the VSS, it initiates a visibility key exchange with the server to establish a fresh VSS, performing steps 1-5 above with role reversal, the middlebox being now the initiator.

The purpose of using a proposal key and a confirmation key to identify the precomputed VSS at handshake-time, instead of just a hash of the VSS, is to allow the server to verify that the middlebox knows the VSS, and otherwise terminate the handshake to avoid setting up a TLS connection that the middlebox cannot deprotect. As additional mitigation of deprotection-interference attacks, the server could require the middlebox to confirm receipt of each of the messages that the server uses to transmit the protection states, at the latency cost of an additional roundtrip per message on the long term TCP connection.

Preservation of Forward Secrecy

Traditional TLS visibility solutions decrypt traffic by provisioning to the middlebox the same static RSA private key used by the server to decrypt the premaster secret generated by the client. Such visibility solutions can no longer be used with TLS 1.3 because TLS 1.3 does not support RSA key transport. The only key exchange methods supported by TLS 1.3, besides using a pre-shared key by itself, require the use of an ephemeral rather than static private key. So no visibility solutions based on the provisioning of a private key can be used with TLS 1.3.

Traditional visibility solutions support TLS 1.2, but only by downgrading the security that browsers have now been providing for years. As can be seen here, in April 2017 Chrome and Firefox already listed ECDHE cipher suites as their preferred ones at the beginning of the cipher_suites field in ClientHello. Traditional visibility solutions must force a TLS 1.2 browser to use less preferred cipher suites that use static private keys.

All three variants of the proposed VSS-based visibility solution work with all key exchange modes of TLS 1.3, and preserve forward secrecy for the two that provide forward secrecy: (EC)DHE and PSK + (EC)DHE. The 2V variant, besides supporting TLS 1.3, allows the use of TLS 1.2 with any cipher suite, including the ECDHE cipher suites preferred by browsers, and preserves the forward secrecy provided by the ECDHE cipher suites.

When ephemeral key pairs are used in TLS 1.2 or TLS 1.3 to establish the TLS shared secret and the 2V variant is used to provide traffic visibility, an adversary who records the TLS traffic between the client and the server, as well as the messages between the middlebox and the server on the long term TCP connection, cannot decrypt the TLS traffic even if a security breach occurs in the future after termination of the TLS connection, provided that the following precautions are taken:

• The middlebox and the server securely delete their visibility private keys after computing or precomputing the VSS.
• The middlebox and the server securely delete the VSS after computing the visibility AEAD key used to protect messages conveying traffic keys from the server to the middlebox.
• The middlebox and the server securely delete the visibility AEAD key by the end of the connection.
• The client and the server securely delete their ephemeral TLS private keys after computing the TLS shared secret, called the premaster secret in TSL 1.2 or the (EC)DHE shared secret in TLS 1.3.
• The client and the server securely delete the TLS shared secret, all traffic keys, and all intermediate secrets used in the derivation of traffic keys from the TLS shared secret, by the end of the connection.
• The middlebox securely deletes all traffic keys received from the server by the end of the connection.