The 0-RTT Feature of TLS 1.3 Can Be Used As an Encrypted Steganographic Channel to Operate a Backdoor into an Enterprise Network

The TLS 1.3 specification in RFC 8446 allows the client to send application data to the server immediately after the ClientHello message, with zero round-trip time, and refers to that data as 0-RTT data or early data.

A server that receives early data may accept it or reject it. Rejected data is ignored by the server but seen by all routers, switches, firewalls and other network appliances in the network path from the client to the server. Therefore an attacker-controlled client can use rejected early data as a steganographic channel to communicate with any compromised network appliance situated in the network path. Furthermore neither the server, nor any of the TLS visibility solutions that are currently in the market among those that I surveyed in an earlier post, attempt to decrypt rejected early data. Hence the attacker-controlled client can encrypt the channel using a key unknown to the server but shared with the compromised appliance without risking detection.

An attacker who has implanted persistent malware on an enterprise network appliance can therefore use rejected early data as an encrypted steganographic channel to send command-and-control (C2) instructions from an external client to the implant in the compromised appliance and thus operate a backdoor into the enterprise network.

In this post I go over some of the details of the 0-RTT feature of TLS 1.3, describe several methods that an attacker-controlled client can use to cause rejection of early data by the server, sketch out an attack scenario and propose mitigations.

Continue reading “The 0-RTT Feature of TLS 1.3 Can Be Used As an Encrypted Steganographic Channel to Operate a Backdoor into an Enterprise Network”

Nubeva Explains How It handles TLS 1.3 Key Updates in Response to Pomcor Blog Post

In the last post of the TLS traffic visibility series, before a survey of solutions, I drew attention to how in TLS 1.3 different kinds of traffic are protected under different keys and sometimes with different ciphers, and how client and server can update their application traffic keys at any time. I referred to this as the multiple protection state problem of TLS 1.3.

This problem means that PFS visibility solutions where a single symmetric session key per direction of traffic is sent to a passive visibility middlebox will not work for TLS 1.3 even if they work for TLS 1.2. I mentioned two such solutions in the previous post, one of them being Nubeva’s Symmetric Key Intercept (SKI), described in a presentation at a NIST workshop.

In response to the blog post, Nubeva has sent me a detailed explanation of how their SKI solution handles the multiplicity of symmetric keys in TLS 1.3. It turns out that, although the solution is called Symmetric Key Intercept and the workshop presentation referred to the extraction of symmetric keys from system memory, it is not the symmetric keys that are extracted and sent to a decryptor, but rather the TLS 1.3 traffic secrets, from which the symmetric keys are derived by the decryptor as described in Nubeva’s response.

Continue reading “Nubeva Explains How It handles TLS 1.3 Key Updates in Response to Pomcor Blog Post”

A Survey of Existing and Proposed TLS Visibility Solutions

This is the fifth and last 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.

Update. This post has been updated in response to a clarification received from Nubeva. See the section on SKI below and the next blog post.

It is well known that TLS 1.3 has created a visibility problem for encrypted intranet traffic by removing the static RSA key exchange method. Except in PSK-only mode, TLS 1.3 traffic has forward secrecy protection and cannot be decrypted by a passive middlebox provisioned with a static private key. This is known as the PFS visibility problem, where PFS stands for “perfect” forward secrecy.

But there is no awareness yet of a second problem created by TLS 1.3 that makes it harder to solve the PFS visibility problem than is generally understood. I call it the multiple protection state problem.

TLS 1.2 has PFS cipher suites, and therefore it has its own PFS visibility problem. If a client insists on using a PFS cipher suite, a passive middlebox provisioned with a static private key won’t be able to decrypt the traffic. Some existing TLS visibility solutions provide the middlebox with the symmetric keys used to protect the traffic, rather than with the private key used to perform the key exchange. Such solutions are being successfully deployed for decrypting TLS 1.2 traffic. But the multiple protection state problem means that those solutions are not applicable to TLS 1.3.

I realized this as I was working on a survey of TLS visibility solutions. The problem is described in the next section and the survey can be found in the following section.

Continue reading “A Survey of Existing and Proposed TLS Visibility Solutions”

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.

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

Extending the TLS 1.3 Visibility Solution to Include PSK and 0-RTT

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

Update. This post has been updated to say that, in the ST variant, the messages that convey the traffic secrets also convey the two-byte designation of the cipher suite that specifies the AEAD algorithm to be used with the keys derived from the secrets, and that the messages include the connection ID of the client-server connection as the AEAD associated data. The middlebox needs to be told what algorithm to use to decrypt early data if the early data is rejected by the server.

TLS 1.3 has created a problem for enterprises by discontinuing all key exchange methods that use static key pairs. In the first post of this series I described a solution to this problem that preserves forward secrecy, based on the establishment of an ephemeral shared secret between the TLS server and a visibility middlebox. In the second post I provided full details of the solution for the (EC)DHE-only key exchange mode of TLS 1.3. In this post I show how the solution can be extended to handle the PSK-only and PSK + (EC)DHE key exchange modes and the 0-RTT feature of TLS 1.3 by providing the PSK to the middlebox. In this post I also introduce a variant of the solution that handles the PSK modes without the middlebox having to know the PSK and provides different benefits. Both variants can be used in all three key exchange modes of TLS 1.3.

Continue reading “Extending the TLS 1.3 Visibility Solution to Include PSK and 0-RTT”

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.

Continue reading “Protocol-Level Details of the TLS 1.3 Visibility Solution”

Reconciling Forward Secrecy with Network Traffic Visibility in Enterprise Deployments of TLS 1.3

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

Update. I have corrected the post to say that the middlebox and the server must both use an ephemeral key pair for their key exchange.

Update. I said that the TLS server uses a key derivation function to derive a key pair from the secret that it shares with the middlebox. I should have said, more precisely, that it uses the secret to derive bits that are then used to generate a key pair. I’ve corrected this below, and I will write another post to provide more details.

TLS 1.3 has removed the static RSA and static Diffie-Hellman cipher suites, so that all key exchange mechanisms based on public-key cryptography now provide forward secrecy. This is great for security, but creates a problem for enterprise deployments of the TLS protocol.

As explained in the Enterprise Transport Security specification of the European Telecommunications Standards Institute (ETSI), enterprises need to inspect the network traffic inside their data centers for reasons including application health monitoring, troubleshooting, intrusion detection, detection of malware activity, detection of denial-of-service attacks, and compliance audits.

Visibility of plaintext network traffic is usually achieved by means of passive middleboxes that observe the encrypted network traffic and are able to decrypt it. When a middlebox observes a TLS 1.2 key exchange, if the server uses a static RSA or static Diffie-Hellman key pair and the middlebox is provided with a copy of the private key component of the static key pair, the middlebox can compute the session keys in the same manner as the server, and use the session keys to decrypt the subsequent traffic.

The problem is that this method cannot be used with TLS 1.3, and enterprise data centers cannot refuse to upgrade and get stuck at TLS 1.2 forever.

The above mentioned ETSI specification proposes a clever solution. The TLS client and server follow the TLS 1.3 specification, but the server cheats by using a static Diffie-Hellman key pair while pretending to use an ephemeral one, and shares the static private key with the middlebox. This solution works, but fails to achieve the security benefit of forward secrecy.

I would like to propose instead a solution, illustrated in Figure 1, that requires no cheating and achieves both forward secrecy and visibility of the traffic plaintext to the middlebox.

Figure 1

The TLS client and the TLS server fully implement TLS 1.3. When the server and the middlebox see the ClientHello message, they perform a Diffie-Hellman (DH) or Elliptic Curve Diffie-Hellman (ECDH) key exchange where each side (server and middlebox) uses an ephemeral key pair whose public key component is signed by the private key component of a long-term signature key pair. The result of this (EC)DH key exchange is an ephemeral secret shared between the TLS server and the middlebox. The TLS server uses that shared secret to derive bits, by means of a key derivation algorithm such as HKDF, that it in turn uses to generate an (EC)DH key pair that it uses in the TLS key exchange. This (EC)DH key pair is ephemeral and provides forward secrecy, because it is derived from the ephemeral shared secret. The middlebox uses the shared secret to derive the same ephemeral (EC)DH key pair in the same manner as the TLS server. Then it uses that shared ephemeral key pair to compute the session keys, and uses the session keys to decrypt the subsequent traffic.

Next post in this series: Protocol-Level Details of the TLS 1.3 Visibility Solution.

NSA’s FAQs Demystify the Demise of Suite B, but Fail to Explain One Important Detail

Last July, the National Security Agency (NSA) issued CNSS Advisory Memorandum 02-15, available at the Advisory Memoranda page, updating the list of cryptographic algorithms that can be used in National Security Systems (NSS). A subsequent document referred to the new algorithms as the Commercial National Security Algorithm Suite (CNSA Suite), which replaces Suite B. The transition to the CNSA Suite took place two months before a Suite B deadline to discontinue the use of RSA, DH and DSA and rely exclusively on ECC algorithms for public key cryptosystems. The subsequent document explained the motivation for the transition by saying that “the growth of elliptic curve use has bumped up against the fact of continued progress in the research on quantum computing, which has made it clear that elliptic curve cryptography is not the long term solution many once hoped it would be,” and announced “preliminary plans” for a future transition to quantum-resistant algorithms.

This abrupt change of course, following many years of promoting ECC, took the cryptographic community by surprise. Continue reading “NSA’s FAQs Demystify the Demise of Suite B, but Fail to Explain One Important Detail”

Has Bluetooth Become Secure?

Bluetooth has a bad reputation when it comes to security. Many vulnerabilities have been found over the years in the technology, and many successful attacks have been demonstrated against it. But the Bluetooth specification has also changed much over the years, and each revision of the specification has made substantial changes to the Bluetooth security protocols. Whether the latest protocols are secure is a question open to debate. This question is especially important when Bluetooth is used in emerging medical and Internet-of-Things applications where security flaws have safety implications. But it has also come up recently in the context of the Derived Credentials being standardized by NIST for authentication of Federal employees who use mobile devices.

(This is a continuation of the last two posts, which reported on the recent NIST Workshop on PIV-Related Special Publications. It is also the last of a seven-part series of posts discussing the public comments on Draft SP 800-157: Guidelines for Derived Personal Identity Verification (PIV) Credentials, and the final version of the publication. Links to all the posts in the series can be found here.)

Before tackling the question of whether Bluetooth is secure today, Continue reading “Has Bluetooth Become Secure?”

Identity-Based Protocol Design Patterns for Machine-to-Machine Secure Channels

Cryptography is an essential tool for addressing the privacy and security issues faced by the Web and the Internet of Things. Sadly, however, there is a chronic technology transfer failure that causes important cryptographic techniques to be underutilized.

An example of an underutilized technique is Identity-Based Cryptography. It is used for secure email, although not broadly. But, to my knowledge, it has never been used to implement secure channel protocols, even though it has the potential to provide great practical advantages over traditional public key infrastructure if put to such usage. We pointed this out in our white paper on TLS. Now we have also shown the benefits of identity-based cryptography for machine-to-machine communications, in a new paper that we will present at the Workshop on Security and Privacy in Machine-to-Machine Communications (M2MSec, San Francisco, October 29, 2014). Machine-to-machine communications fall into many different use cases with very different requirements. So, instead of proposing one particular technique, we propose in the paper four different protocol design patterns that could be used to specify a variety of different protocols.

Update (August 4). I should point out that there is a proposal to use Identity-Based authenticated key exchange in conjunction with MIKEY (Multimedia Internet KEYing), a key management scheme for SRTP (Secure Real-Time Transport Protocol), which itself is used to provide security for audio and video conferencing on the Internet. The proposed authenticated key exchange protocol is called MIKEY-IBAKE and is described in RFC 6267. This is an informational RFC rather than a standards-track RFC, so it’s not clear if the proposed authenticated key exchange method will be eventually deployed. Interestingly, MIKEY-IBAKE uses identity-based encryption rather than identity-based key agreement. This is also what we do in the M2MSec paper, but with a difference. MIKEY-IBAKE uses identity-based encryption to carry ephemeral Elliptic Curve Diffie-Hellman parameters, and thus does not reduce the number of roundtrips. We use identity-based encryption to send a secret from the initiator to the responder, and we eliminate roundtrips by simultaneously sending application data protected with encryption and authentication keys derived from the secret. This gives up replay protection and forward secrecy for the first message; but replay protection, as well as forward secrecy in two of the four patterns, are provided from the second message onward.