| uta | Y. Sheffer |
| Internet-Draft | Porticor |
| Intended status: Informational | R. Holz |
| Expires: March 13, 2015 | TUM |
| P. Saint-Andre | |
| &yet | |
| September 9, 2014 |
Summarizing Current Attacks on TLS and DTLS
draft-ietf-uta-tls-attacks-03
Over the last few years there have been several serious attacks on TLS, including attacks on its most commonly used ciphers and modes of operation. This document summarizes these attacks, with the goal of motivating generic and protocol-specific recommendations on the usage of TLS and DTLS.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on March 13, 2015.
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
Over the last few years there have been several major attacks on TLS [RFC5246], including attacks on its most commonly used ciphers and modes of operation. Details are given in Section 2, but suffice it to say that both AES-CBC and RC4, which together make up for most current usage, have been seriously attacked in the context of TLS.
This situation motivated the creation of the UTA working group, which is tasked with the creation of generic and protocol-specific recommendations for the use of TLS and DTLS.
"Attacks always get better; they never get worse" (ironically, this saying is attributed to the NSA). This list of attacks describes our knowledge as of this writing. It seems likely that new attacks will be invented in the future.
For a more detailed discussion of the attacks listed here, the interested reader is referred to [Attacks-iSec].
This section lists the attacks that motivated the current recommendations. This is not intended to be an extensive survey of TLS's security.
While there are widely deployed mitigations for some of the attacks listed below, we believe that their root causes necessitate a more systemic solution.
Various attacks attempt to remove the use of SSL/TLS altogether, by modifying unencrypted protocols that request the use of TLS, specifically modifying HTTP traffic and HTML pages as they pass on the wire. These attacks are known collectively as SSL Stripping and were first introduced by Moxie Marlinspike [SSL-Stripping]. In the context of Web traffic, these attacks are only effective if the client initially accesses a Web server using HTTP. A commonly used mitigation is HTTP Strict Transport Security (HSTS) [RFC6797].
Similarly, there are attacks on the transition between unprotected and TLS-protected traffic. A number of IETF application protocols have used an application-level command, usually STARTTLS, to upgrade a clear-text connection to use TLS. Multiple implementations of STARTTLS had a flaw where an application-layer input buffer retained commands that were pipelined with the STARTTLS command, such that commands received prior to TLS negotiation are executed after TLS negotiation. This problem is resolved by requiring the application-level command input buffer to be empty before negotiating TLS. Note that this flaw lives in the application layer code and does not impact the TLS protocol directly.
The BEAST attack [BEAST] uses issues with the TLS 1.0 implementation of CBC (that is, the predictable initialization vector) to decrypt parts of a packet, and specifically to decrypt HTTP cookies when HTTP is run over TLS.
A consequence of the MAC-then-encrypt design in all current versions of TLS is the existence of padding oracle attacks [Padding-Oracle]. A recent incarnation of these attacks is the Lucky Thirteen attack [CBC-Attack], a timing side-channel attack that allows the attacker to decrypt arbitrary ciphertext.
The Lucky Thirteen attack can be mitigated by using authenticated encryption like AES-GCM [RFC5288] or encrypt-then-mac [I-D.ietf-tls-encrypt-then-mac] instead of the TLS default of MAC-then-encrypt.
The RC4 algorithm [RC4] has been used with TLS (and previously, SSL) for many years. RC4 has long been known to have a variety of cryptographic weaknesses, e.g. [RC4-Attack-Pau], [RC4-Attack-Man], [RC4-Attack-FMS]. Recent cryptanalysis results [RC4-Attack-AlF] exploit biases in the RC4 keystream to recover repeatedly encrypted plaintexts.
These recent results are on the verge of becoming practically exploitable; currently they require 2^26 sessions or 13x2^30 encryptions. As a result, RC4 can no longer be seen as providing a sufficient level of security for TLS sessions. For further details, the reader is referred to [I-D.ietf-tls-prohibiting-rc4].
The CRIME attack [CRIME] (CVE-2012-4929) allows an active attacker to decrypt ciphertext (specifically, cookies) when TLS is used with TLS level compression.
The TIME attack [TIME] and the later BREACH attack [BREACH] (CVE-2013-3587, though the number has not been officially allocated) both make similar use of HTTP-level compression to decrypt secret data passed in the HTTP response. We note that compression of the HTTP message body is much more prevalent than compression at the TLS level.
The former attack can be mitigated by disabling TLS compression. We are not aware of mitigations at the TLS protocol level to the latter attack, and so application-level mitigations are needed (see [BREACH]). For example, implementations of HTTP that use CSRF tokens will need to randomize them even when the recommendations of [I-D.ietf-uta-tls-bcp] are adopted.
There have been several practical attacks on TLS when used with RSA certificates (the most common use case). These include [Bleichenbacher98] and [Klima03]. While the Bleichenbacher attack has been mitigated in TLS 1.0, the Klima attack that relies on a version-check oracle is only mitigated by TLS 1.1.
The use of RSA certificates often involves exploitable timing issues [Brumley03] (CVE-2003-0147), unless the implementation takes care to explicitly eliminate them.
A recent certificate fuzzing tool [Brubaker2014using] uncovered numerous vulnerabilities in different TLS libraries, related to certificate validation.
TLS allows to define ephemeral Diffie-Hellman and Elliptic Curve Diffie-Hellman parameters in its respective key exchange modes. This results in an attack detailed in [Cross-Protocol]. In addition, clients that do not properly verify the received parameters are exposed to man in the middle (MITM) attacks. Unfortunately the TLS protocol does not require this verification, see [RFC6989] for the IPsec analogy.
A major attack on the TLS renegotiation mechanism applies to all current versions of the protocol. The attack and the TLS extension that resolves it are described in [RFC5746].
The triple handshake attack [[TRIPLE-HS, add the reference when published]] 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].
A recent article [Delignat14] describes a security issue whereby SSLv3 fallback and improper handling of session caches on the server side can be abused by an attacker to establish a malicious connection to a virtual host other than originally intended and approved by the server. This attack is especially serious in performance critical environments where sharing of SSLv3 session caches is very common.
Server CPU power has progressed over the years so that TLS can now be turned on by default. However the risk of malicious clients and coordinated groups of clients ("botnets") mounting denial of service attacks is still very real. TLS adds another vector for computational attacks, since a client can easily (with little computational effort) force the server to expend relatively large computational work. It is known that such attacks have in fact been mounted.
Even when the protocol is fully specified, the are very common issues that often plague implementations. In particular, the integration of higher-level protocols, TLS and its PKI-based authentication is the source of misunderstandings and implementation "shortcuts". An extensive survey of these issues can be found in [Georgiev2012].
DTLS [RFC4347] [RFC6347] is an adaptation of TLS for UDP datagrams.
With respect to the attacks described in the current document, DTLS 1.0 is equivalent to TLS 1.1. The only exception is RC4 which is disallowed in DTLS. DTLS 1.2 is equivalent to TLS 1.2.
This document describes protocol attacks in an informational manner, and in itself does not have any security implications. Its companion documents certainly do.
This document requires no IANA actions. [Note to RFC Editor: please remove this whole section before publication.]
We would like to thank Stephen Farrell, Simon Josefsson, John Mattsson, Yoav Nir, Kenny Paterson, Patrick Pelletier, Tom Ritter and Rich Salz for their review of this document. We thank Andrei Popov for contributing text on RC4, Kohei Kasamatsu for text on Lucky13, Ilari Liusvaara for text on attacks and on DTLS, Aaron Zauner for text on virtual host confusion, Chris Newman for text on STARTTLS command injection.
The document was prepared using the lyx2rfc tool, created by Nico Williams.
Note to RFC Editor: please remove this section before publication.