Handshake Privacy for TLS 1.3 - Technical report

TLS 1.3, the newest version of the Transport Layer Security (TLS) protocol, provides stronger authentication and confidentiality guarantees than prior TLS version. Despite additional encryption of handshake messages, some parts of the TLS 1.3 handshake, including the ClientHello, are still in the clear. For example, the protocol reveals the identity of the target server to network attackers, allowing the passive surveillance and active censorship of TLS connections. A recent privacy extension called Encrypted Client Hello (ECH, previously called ESNI) addresses this problem and offers more comprehensive handshake encryption and privacy for TLS 1.3. Surprisingly however, although the security of the TLS 1.3 handshake has been comprehensively analyzed in a variety of formal models, the privacy guarantees of handshake encryption have never been formally studied. This gap has resulted in several mis-steps: several of the initial designs for ECH were found to be vulnerable to passive and active network attacks. In this paper, we present the first mechanized formal analysis of privacy properties for the TLS 1.3 handshake. We study all standard modes of TLS 1.3, with and without ECH, using the symbolic protocol analyzer ProVerif. We discuss attacks on ECH, some found during the course of this study, and show how they are accounted for in the latest version. Our analysis has helped guide the standardization process for ECH and we provide concrete privacy recommendations for TLS implementors. We also contribute the most comprehensive model of TLS 1.3 to date, which can be used by designers experimenting with new extensions to the protocol. Ours is one of the largest privacy proofs attempted in ProVerif and our modeling strategies may be of general interest to protocol analysts

A Symbolic Analysis of Privacy for TLS 1.3 with Encrypted Client Hello

International audienceTLS 1.3, the newest version of the Transport Layer Security (TLS) protocol, provides strong authentication and confidentiality guarantees that have been comprehensively analyzed in a variety of formal models. However, despite its controversial use of handshake meta-data encryption, the privacy guarantees of TLS 1.3 remain weak and poorly understood. For example, the protocol reveals the identity of the target server to network attackers, allowing the passive surveillance and active censorship of TLS connections. To close this gap, the IETF TLS working group is standardizing a new privacy extension called Encrypted Client Hello (ECH, previously called ESNI), but the absence of a formal privacy model makes it hard to verify that this extension works. Indeed, several early drafts of ECH were found to be vulnerable to active network attacks.In this paper, we present the first mechanized formal analysis of privacy properties for the TLS 1.3 handshake. We study all standard modes of TLS 1.3, with and without ECH, using the symbolic protocol analyzer ProVerif. We discuss attacks on ECH, some found during the course of this study, and show how they are accounted for in the latest version. Our analysis has helped guide the standardization process for ECH and we provide concrete privacy recommendations for TLS implementors. We also contribute the most comprehensive model of TLS 1.3 to date, which can be used by designers experimenting with new extensions to the protocol. Ours is one of the largest privacy proofs attempted using an automated verification tool and may be of general interest to protocol analysts

A Formal TLS Handshake Model in LNT

Testing of network services represents one of the biggest challenges in cyber security. Because new vulnerabilities are detected on a regular basis, more research is needed. These faults have their roots in the software development cycle or because of intrinsic leaks in the system specification. Conformance testing checks whether a system behaves according to its specification. Here model-based testing provides several methods for automated detection of shortcomings. The formal specification of a system behavior represents the starting point of the testing process. In this paper, a widely used cryptographic protocol is specified and tested for conformance with a test execution framework. The first empirical results are presented and discussed.Comment: In Proceedings MARS/VPT 2018, arXiv:1803.0866

Analysing the EAP-TLS handshake and the 4-way handshake of the 802.11i standard

The IEEE 802.11i standard has been designed to enhance security in wireless networks. The EAP-TLS handshake aims to provide mutual authentication between supplicant and authentication server, and then derive the Pairwise Master Key (PMK). In the 4 -way handshake the supplicant and the authenticator use PMK to derive a fresh pairwise transient key (PTK). The PMK is not used directly for security while assuming the supplicant and authenticator have the same PMK before running 4- way handshake. In this paper, the EAP-TLS handshake and the 4-way handshake phases have been analysed with a proposed framework using Isabelle tool. In the analysis, we have found a new Denial-of-Service (DoS) attack in the 4-way handshake. The attack prevents the authenticator from receiving message 4 after the supplicant sends it out. This attack forces the authenticator to re-send the message 3 until time out and subsequently to de-authenticate supplicant. This paper has proposed improvements to the 4-way handshake to avoid the Denial-of-Service attack

Compiling symbolic attacks to protocol implementation tests

Recently efficient model-checking tools have been developed to find flaws in security protocols specifications. These flaws can be interpreted as potential attacks scenarios but the feasability of these scenarios need to be confirmed at the implementation level. However, bridging the gap between an abstract attack scenario derived from a specification and a penetration test on real implementations of a protocol is still an open issue. This work investigates an architecture for automatically generating abstract attacks and converting them to concrete tests on protocol implementations. In particular we aim to improve previously proposed blackbox testing methods in order to discover automatically new attacks and vulnerabilities. As a proof of concept we have experimented our proposed architecture to detect a renegotiation vulnerability on some implementations of SSL/TLS, a protocol widely used for securing electronic transactions.Comment: In Proceedings SCSS 2012, arXiv:1307.802

Analysing and attacking the 4-way handshake of IEEE 802.11i standard

The IEEE 802.11i standard has been designed to enhance security in wireless networks. In the 4-way handshake the supplicant and the authenticator use the pairwise master key (PMK) to derive a fresh pairwise transient key (PTK). The PMK is not used directly for security while assuming the supplicant and authenticator have the same PMK before running 4-way handshake. In this paper, the 4-way handshake phase has been analysed using Isabelle tool to identify a new Denial-of-Service (DoS) attack. The attack prevents the authenticator from receiving message 4 after the supplicant sends it out. This attack forces the authenticator to re-send the message 3 until time out and subsequently to de-authenticate supplicant. This paper has proposed improvements to the 4-way handshake to avoid the Denial-of-Service attack

Observing the Evolution of QUIC Implementations

The QUIC protocol combines features that were initially found inside the TCP, TLS and HTTP/2 protocols. The IETF is currently finalising a complete specification of this protocol. More than a dozen of independent implementations have been developed in parallel with these standardisation activities. We propose and implement a QUIC test suite that interacts with public QUIC servers to verify their conformance with key features of the IETF specification. Our measurements, gathered over a semester, provide a unique viewpoint on the evolution of a protocol and of its implementations. They highlight the arrival of new features and some regressions among the different implementations.Comment: 6 pages, 8 figure