Proving the TLS Handshake Secure (As It Is)

Bhargavan, Karthikeyan; Fournet, Cédric; Kohlweiss, Markulf; Pironti, A.; Strub, Pierre-Yves; Zanella-Béguelin, Santiago

doi:10.1007/978-3-662-44381-1_14

Cited by 60 publications

(43 citation statements)

References 41 publications

Supporting

Mentioning

Contrasting

Unclassified

Order By: Relevance

“…On the other hand, our paper does not challenge the cryptographic security of the core constructions of TLS-most of our attacks apply even under the (theoretical) assumption that clients and servers only use cryptographically strong ciphersuites, as formalized, for example, in [15,35,29,16]. I-B NEW ATTACKS OVER TLS.…”

Section: Transparent Transport Layer Security?mentioning

confidence: 99%

“…To validate them experimentally, we implemented and tested patches for two existing TLS implementations: OpenSSL and miTLS. As future work, we plan to formally model their security benefits by extending the verified cryptographic model of miTLS [15,16]. Simple Verified HTTPS over TLS ( §VIII) In principle, carefully-written applications can defend against these attacks, without the need to change TLS.…”

Section: Transparent Transport Layer Security?mentioning

confidence: 99%

See 1 more Smart Citation

Triple Handshakes and Cookie Cutters: Breaking and Fixing Authentication over TLS

Bhargavan

Lavaud²,

Fournet

et al. 2014

2014 IEEE Symposium on Security and Privacy

Self Cite

133

View full text Add to dashboard Cite

Abstract-TLS was designed as a transparent channel abstraction to allow developers with no cryptographic expertise to protect their application against attackers that may control some clients, some servers, and may have the capability to tamper with network connections. However, the security guarantees of TLS fall short of those of a secure channel, leading to a variety of attacks.We show how some widespread false beliefs about these guarantees can be exploited to attack popular applications and defeat several standard authentication methods that rely too naively on TLS. We present new client impersonation attacks against TLS renegotiations, wireless networks, challenge-response protocols, and channel-bound cookies. Our attacks exploit combinations of RSA and Diffie-Hellman key exchange, session resumption, and renegotiation to bypass many recent countermeasures. We also demonstrate new ways to exploit known weaknesses of HTTP over TLS. We investigate the root causes for these attacks and propose new countermeasures. At the protocol level, we design and implement two new TLS extensions that strengthen the authentication guarantees of the handshake. At the application level, we develop an exemplary HTTPS client library that implements several mitigations, on top of a previously verified TLS implementation, and verify that their composition provides strong, simple application security. I. TRANSPARENT TRANSPORT LAYER SECURITY?TLS is the main Internet Standard for secure communications and still, after 20 years of practice, the security it provides to applications remains problematic.I-A APPLICATIONS VS PROTOCOLS. By design, TLS intends to provide a drop-in replacement of the basic networking functions, such as connect, accept, read and write, that can effortlessly protect any application against a network attacker without the need to understand the protocol or its underlying cryptography. Pragmatically, TLS offers much flexibility, so the security properties provided by the protocol [43,35,32,29] and its implementations [20,14,15] [45], it opens itself to attacks. Furthermore, applications-level security mechanisms increasingly seek to benefit from the underlying TLS connection by reusing its authenticated peer identities, key materials [48], and unique identifiers [6].As a consequence, TLS libraries provide low-level APIs that expose many details of the cryptographic mechanisms and certificates negotiated during successive handshakes. Some application-level libraries, such as CURL, seek to recover the simplicity of a secure channel by implementing an abstraction layer that smooths over the details of TLS by managing sessions, validating certificates, etc. Meanwhile, TLS applications continue to rely on URLs, passwords, and cookies; they mix secure and insecure transports; and they often ignore lower-level signals such as handshake completion, session resumption, and truncated connections.Many persistent problems can be blamed on a mismatch between the authentication guarantees expected by the application and those...

show abstract

Section: Transparent Transport Layer Security?mentioning

confidence: 99%

Section: Transparent Transport Layer Security?mentioning

confidence: 99%

Triple Handshakes and Cookie Cutters: Breaking and Fixing Authentication over TLS

Bhargavan

Lavaud²,

Fournet

et al. 2014

2014 IEEE Symposium on Security and Privacy

Self Cite

133

View full text Add to dashboard Cite

show abstract

“…In view of its importance, TLS has long been the subject of intense research analysis and attacks, including, in chronological order, [56,17,52,39,36,55,23,37,5,49,33,6,50,28,51,11,2,34,48,29,19,48,3,12,4,13,10]. Particular attention has been given in recent works to the analysis of TLS 1.2, starting with variants of the protocol in [36,50], to the cryptographic core in [34,43,31,45] and then a more complete specification [14]. The recent QUIC protocol from Google by Langley and Chang [44], designed to add support to the 0-RTT setting, has also been the subject of formal analysis by Fischlin and Günther [30] and by Lychev et al [46].…”

Section: Introductionmentioning

confidence: 99%

The OPTLS Protocol and TLS 1.3

Krawczyk¹,

Wee

2016

2016 IEEE European Symposium on Security and Privacy (EuroS&P)

View full text Add to dashboard Cite

We present the OPTLS key-exchange protocol, its design, rationale and cryptographic analysis. OPTLS design has been motivated by the ongoing work in the TLS working group of the IETF for specifying TLS 1.3, the next-generation TLS protocol. The latter effort is intended to revamp the security of TLS that has been shown inadequate in many instances as well as to add new security and functional features. The main additions that influence the cryptographic design of TLS 1.3 (hence also of OPTLS) are a new "0-RTT requirement" (0-RTT stands for "zero round trip time") to allow clients that have previously retrieved or cached the public key of the server to send protected data already in the first flow of the protocol; making perfect forward secrecy (PFS) a mandatory requirement; and moving to elliptic curves as the main cryptographic basis for the protocol (for performance and security reasons). Accommodating these requirements calls for moving away from the RSA-centric design of TLS in favor of a protocol based on Diffie-Hellman techniques. OPTLS offers a simple design framework that supports all the above requirements from the protocol with a uniform and modular logic that helps in the specification, analysis, performance optimization, and future maintenance of the protocol. The current (draft) specification of TLS 1.3 builds upon the OPTLS framework as a basis for the cryptographic core of the handshake protocol adapting the different modes of OPTLS to the TLS 1.3 context.

show abstract

“…This has become an active field of research in the last few years (see, e.g., [25], [27], [28], [29], [30], [31] for some of the recent works). More specifically, we use the CVJ framework (cryptographic verification of Java programs) proposed by Küsters, Truderung, and Graf [25] for this purpose.…”

Section: Introductionmentioning

confidence: 99%

A Hybrid Approach for Proving Noninterference of Java Programs

Küsters

Truderung

Beckert

et al. 2015

2015 IEEE 28th Computer Security Foundations Symposium

View full text Add to dashboard Cite

Several tools and approaches for proving noninterference properties for Java and other languages exist. Some of them have a high degree of automation or are even fully automatic, but overapproximate the actual information flow, and hence, may produce false positives. Other tools, such as those based on theorem proving, are precise, but may need interaction, and hence, analysis is time-consuming.In this paper, we propose a hybrid approach that aims at obtaining the best of both approaches: We want to use fully automatic analysis as much as possible and only at places in a program where, due to overapproximation, the automatic approaches fail, we resort to more precise, but interactive analysis, where the latter involves the verification only of specific functional properties in certain parts of the program, rather than checking more intricate noninterference properties for the whole program.To illustrate the hybrid approach, in a case study we use this approach-along with the fully automatic tool Joana for checking noninterference properties for Java programs and the theorem prover KeY for the verification of Java programs-as well as the CVJ framework proposed by Küsters, Truderung, and Graf to establish cryptographic privacy properties for a non-trivial Java program, namely an e-voting system. The CVJ framework allows one to establish cryptographic indistinguishability properties for Java programs by checking (standard) noninterference properties for such programs.

show abstract

Proving the TLS Handshake Secure (As It Is)

Cited by 60 publications

References 41 publications

Triple Handshakes and Cookie Cutters: Breaking and Fixing Authentication over TLS

Triple Handshakes and Cookie Cutters: Breaking and Fixing Authentication over TLS

The OPTLS Protocol and TLS 1.3

A Hybrid Approach for Proving Noninterference of Java Programs

Contact Info

Product

Resources

About