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

Inspection-Friendly TLS/HTTPS

As the Internet grows, Transport Layer Security (TLS) is becoming the standard to secure end-to-end encrypted communication. However, end-to-end encryption can detract from user privacy, as many IoT devices have been revealed to track excessive user data. The use of encryption makes it impossible for users to determine which - if any - private data is being sent. Inspection-Friendly TLS (IF-TLS) is a protocol we designed that shares decryption keys with middleboxes for the purpose of inspecting IoT traffic. The user specifies these middleboxes, thus giving the users more control over the device data. Without a middlebox in the connection, we observed a reasonable initialization time compared to TLS 1.3, as well as similar data round-trip times compared to TLS 1.3

Formal verification of the W3C Web Authentication Protocol

International audienceThe science of security can be set on rm foundations via the formal verication of protocols. New protocols can have their design validated in a mechanized manner for security aws, allowing protocol designs to be scientically compared in a neutral manner. Given that these techniques have discovered critical aws in protocols such as TLS 1.2 and are now being used to redesign protocols such as TLS 1.3, we demonstrate how formal verication can be used to analyze new protocols such as the W3C Web Authen-tication API. We model W3C Web Authentication with the formal verication language ProVerif, showing that the protocol itself is secure. However, we also stretch the boundaries of formal verica-tion by trying to verify the privacy properties of W3C Web Authen-tication given in terms of the same origin policy. We use ProVerif to show that without further mandatory requirements in the speci-cation, the claimed privacy properties do not hold. Next steps on how formal verication can be further integrated into standards and the further development of the privacy properties of W3C Web Authentication is outlined

Oblivious Inspection: On the Confrontation between System Security and Data Privacy at Domain Boundaries

In this work, we introduce the system boundary security vs. privacy dilemma, where border devices (e.g., firewall devices) require unencrypted data inspection to prevent data exfiltration or unauthorized data accesses, but unencrypted data inspection violates data privacy. To shortcut this problem, we present Oblivious Inspection, a novel approach based on garbled circuits to perform a stateful application-aware inspection of encrypted network traffic in a privacy-preserving way. We also showcase an inspection algorithm for Fast Healthcare Interoperability Resources (FHIR) standard compliant packets along with its performance results. The results point out the importance of the inspection function being aligned with the underlying garbled circuit protocol. In this line, mandatory encryption algorithms for TLS 1.3 have been analysed observing that packets encrypted using Chacha20 can be filtered up to 17 and 25 times faster compared with AES128-GCM and AES256-GCM, respectively. All together, this approach penalizes performance to align system security and data privacy, but it could be appropriate for those scenarios where this performance degradation can be justified by the sensibility of the involved data such as healthcare scenarios

Tracking Users across the Web via TLS Session Resumption

User tracking on the Internet can come in various forms, e.g., via cookies or by fingerprinting web browsers. A technique that got less attention so far is user tracking based on TLS and specifically based on the TLS session resumption mechanism. To the best of our knowledge, we are the first that investigate the applicability of TLS session resumption for user tracking. For that, we evaluated the configuration of 48 popular browsers and one million of the most popular websites. Moreover, we present a so-called prolongation attack, which allows extending the tracking period beyond the lifetime of the session resumption mechanism. To show that under the observed browser configurations tracking via TLS session resumptions is feasible, we also looked into DNS data to understand the longest consecutive tracking period for a user by a particular website. Our results indicate that with the standard setting of the session resumption lifetime in many current browsers, the average user can be tracked for up to eight days. With a session resumption lifetime of seven days, as recommended upper limit in the draft for TLS version 1.3, 65% of all users in our dataset can be tracked permanently.Comment: 11 page

DSTC: DNS-based Strict TLS Configurations

Most TLS clients such as modern web browsers enforce coarse-grained TLS security configurations. They support legacy versions of the protocol that have known design weaknesses, and weak ciphersuites that provide fewer security guarantees (e.g. non Forward-Secrecy), mainly to provide backward compatibility. This opens doors to downgrade attacks, as is the case of the POODLE attack [18], which exploits the client's silent fallback to downgrade the protocol version to exploit the legacy version's flaws. To achieve a better balance between security and backward compatibility, we propose a DNS-based mechanism that enables TLS servers to advertise their support for the latest version of the protocol and strong ciphersuites (that provide Forward-Secrecy and Authenticated-Encryption simultaneously). This enables clients to consider prior knowledge about the servers' TLS configurations to enforce a fine-grained TLS configurations policy. That is, the client enforces strict TLS configurations for connections going to the advertising servers, while enforcing default configurations for the rest of the connections. We implement and evaluate the proposed mechanism and show that it is feasible, and incurs minimal overhead. Furthermore, we conduct a TLS scan for the top 10,000 most visited websites globally, and show that most of the websites can benefit from our mechanism

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