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.

Pomcor Granted Patent on How to Implement a PKI on a Blockchain

Pomcor has just been granted US Patent 10,764,067, “Operation of a Certificate Authority on a Distributed Ledger”. A distributed ledger is a database replicated across of set of nodes and populated by transactions issued by the nodes. A distributed consensus algorithm is used to achieve consensus among the nodes on the order of the ledger transactions. A blockchain is a distributed ledger in which ledger transactions are grouped into blocks, and consensus on the ordering of the ledger transactions is based on consensus on the validity and ordering of the blocks.

Some distributed ledgers, e.g. the Ethereum blockchain, provide on-ledger storage by allowing a ledger transaction to contain an instruction to store data in an abstract ledger store identified by a ledger address. As ledger transactions including such instructions are propagated to the nodes of the ledger through the peer-to-peer protocol each node executes the instruction locally, on a local replica of the abstract ledger store that is part of the node’s local replica of the ledger state.

A public key infrastructure is a system for issuing, revoking and validating public key certificates, implemented by a hierarchy of certificate authorities (CAs). The storage replication functionality provided by a distributed ledger with on-ledger storage can greatly simplify the implementation of a PKI.

I do not advocate setting up a blockchain or other distributed ledger just for the purpose of implementing a PKI. But if a distributed ledger has already been set up or is being set up for some other purpose, it can be opportunistically used to implement a PKI, or to simplify the operation of an existing PKI.

I also do not advocate storing or transmitting certificates on the blockchain. That would be a bad idea for privacy reasons, and there is no need to do so. A CA operating on a distributed ledger can issue any kind of certificates, including certificates whose subject is a machine, such as a web server or an IoT device, and certificates whose subject is a person. Each kind of certificate can be stored together with the corresponding private key in any kind of secure storage customarily used for that kind of certificate. In a presentation at ICMC 2017 I explained how JavaScript Web APIs can be used to store personal cryptographic credentials in the browser.

Here is a summary of how a PKI can be implemented on a distributed ledger; details can be found in the patent. A subject requests a certificate as usual by submitting a certificate signing request (CSR). The CA creates a certificate and transmits it to the subject, without ledger involvement in the transmission; there is no need for the subject to have access to the ledger. But the CA also issues an issuance transaction on the ledger with an instruction to store a cryptographic hash of the certificate in a certificate issuance store controlled by the CA; and when the certificate needs to be revoked, it issues a revocation transaction on the ledger with an instruction to store the serial number of the certificate in a certificate revocation store also controlled by the CA. As those transactions propagate throughout the ledger, the instructions are executed by all the nodes in their local replicas of the stores.

This greatly simplifies the process of verifying that a certificate is valid.

Instead of verifying the signature on the certificate, the verifier can just check that the hash of the certificate is present in the certificate issuance store controlled by the CA that has issued the certificate. In fact, the signature can be omitted from the certificate if all verifiers have access to the ledger, substantially reducing the size of the certificate and thus the bandwidth and latency cost of presenting the certificate.

And the verifier can check that the certificate has not been revoked simply by checking that its serial number is not present in the certificate revocation store controlled the CA. This obviates the need for the CA to provide a highly available Online Certificate Status Protocol (OCSP) server and/or a regularly updated Certificate Revocation List (CRL); and for the verifier to query the OCSP server or maintain a local copy of the CRL by periodically retrieving signed updates.

Request for Comments: A Possible-Worlds Semantics for Kolmogorov’s Axiomatization of Probability Theory

Probability theory is being very successfully used in a growing number of fields of science and engineering. It is essential to several areas of computer science that I am interested in, including areas critical to cybersecurity and privacy such as cryptogaphy, biometrics, artificial intelligence and human-computer interaction.

The success of probability theory has been made possible by the elegant formalization that was provided by Kolmogorov in his 1933 treatise, which is universally accepted by practitioners as the foundation of modern probability theory.

Curiously, however, in spite of the practical success of probability theory and the universal acceptance of Kolmogorov’s formalization as its foundation, the meaning of the concept of probability has been an open question in philosophy for three centuries, and still is today, as can be seen in this entry of the Stanford Encyclopedia of Philosophy. To try to understand why this is so, I’ve looked at the interpretation of his own formalization that Kolmogorov provides in his treatise.

It turns out that Kolmogorov’s interpretation is inconsistent with his formalization. Later authors, while keeping the formalization, have moved away from the interpretation, but without providing a satisfactory alternative. In this paper I propose an interpretation where the elements of the set that Kolmogorov called E and is now called Ω are possible worlds, in the simplest sense of the term, without complications such as Kripke’s frames necessitated by modal logic. I also propose an intensional definition of the notion of event as a condition on the values of one or more random variables, the less intuitive traditional definition as a subset of Ω being then more easily understood as the extensional counterpart of the intensional definition.

Comments on the paper would be very welcome.

Airport Security in the Age of COVID-19

As the travel restrictions imposed to control the coronavirus pandemic are beginning to be relaxed in some parts of the world, it is time to start rethinking airport security in the age of COVID-19. Even if an effective vaccine is found for COVID-19, it will be out of the question to go back to long lines at security checkpoints and boarding gates, and the manual checking of identity documents and boarding passes.

In a provisional patent application that I coauthored with Karen Lewison before the pandemic and have now published, we proposed an automated method of verifying the identity of travelers that could be used in the post-pandemic world to speed up the security check and the boarding process, and to eliminate the face-to-face interaction with a security officer at the checkpoint and a flight attendant at the boarding gate. The method takes advantage of the high accuracy achieved by today’s deep neural networks for face recognition, while overcoming the privacy concerns raised by the collection and storage of facial images.

Here is a summary of the method.

Continue reading “Airport Security in the Age of COVID-19”