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