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

Abstract

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...

Proving the TLS Handshake Secure (As It Is)

“…It may seem desirable to guarantee a strong relationship between such connections, but our Property (4) guarantees agreement only for the sequence of epochs over a single connection. Indeed, the natural extension of this property to multiple connections does not hold for TLS, as shown by the triple handshake attack of Bhargavan et al [10]. In this attack, an unsafe server-authenticated session is resumed on a new connection and then renegotiated with a new safe mutually-authenticated session.…”

“…Consequently, it is possible for a client and server instance to have a safe epoch but inconsistent variable assignments for the session associated with a prior resumed epoch; this leads to a variety of attacks, similar to the renegotiation attacks of Ray [56]. A stronger agreement can be achieved either at the application level, by checking agreement on prior connections, or by a protocol extension that includes a hash of the log of the original session in resumption handshakes [10]; we leave the modeling of this extension and its security for future work.…”

“…This is in sharp contrast with prior work on the provable security of TLS [30,37,39], which focus on a fixed run of the protocol, for a fixed choice of algorithms. (See §7.1 for a detailed discussion of related work on provable security for TLS, and [10] for recent attacks involving triple handshakes. )…”

Secure modular password authentication for the web using channel bindings

“…The Triple Handshake Attack [14] shows that TLS channel binding via tls-unique and tls-server-endpoint are not secure when session resumption is allowed, since an attacker can cause two distinct sessions to have the same tls-unique binding value via resumption. In order for the techniques proposed in Sects.…”

Summarizing Known Attacks on Transport Layer Security (TLS) and Datagram TLS (DTLS)

“…Triple Handshake (CVE-2014(CVE- -1295 The triple handshake attack [BhargavanDFPS14] enables the attacker to cause two TLS connections to share keying material. This leads to a multitude of attacks, e.g., man-in-the-middle, breaking safe renegotiation, and breaking channel binding via TLS Exporter [RFC5705] or "tls-unique" [RFC5929].…”