One document matched: draft-ietf-uta-tls-attacks-03.xml
<?xml version="1.0" encoding="UTF-8"?>
<?rfc toc="yes"?>
<?rfc symrefs="yes"?>
<?rfc tocindent="no"?>
<?rfc toc="yes"?>
<?rfc symrefs="yes"?>
<?rfc tocindent="no"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
]>
<rfc docName="draft-ietf-uta-tls-attacks-03" ipr="trust200902" category="info">
<front>
<title abbrev="TLS Attacks">Summarizing Current Attacks on TLS and DTLS</title>
<author initials="Y." surname="Sheffer" fullname="Yaron Sheffer">
<organization abbrev="Porticor">Porticor</organization>
<address>
<postal>
<street>29 HaHarash St.</street>
<city>Hod HaSharon</city>
<code>4501303</code>
<country>Israel</country>
</postal>
<email>yaronf.ietf@gmail.com</email>
</address>
</author>
<author initials="R." surname="Holz" fullname="Ralph Holz">
<organization abbrev="TUM">Technische Universitaet Muenchen</organization>
<address>
<postal>
<street>Boltzmannstr. 3</street>
<city>Garching</city>
<code>85748</code>
<country>Germany</country>
</postal>
<email>holz@net.in.tum.de</email>
</address>
</author>
<author initials="P." surname="Saint-Andre" fullname="Peter Saint-Andre">
<organization abbrev="&yet">&yet</organization>
<address>
<email>ietf@stpeter.im</email>
</address>
</author>
<date/>
<workgroup>
uta
</workgroup>
<keyword>Internet-Draft</keyword>
<abstract>
<t>
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.</t>
</abstract>
</front>
<middle>
<section title="Introduction" anchor="d1e329">
<t>
Over the last few years there have been several major attacks on TLS <xref target="RFC5246"/>, including attacks on its most commonly used ciphers and modes of operation. Details are given in <xref target="sec_Attacks"/>, 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.</t>
<t>
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.</t>
<t>
"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.</t>
<t>
For a more detailed discussion of the attacks listed here, the interested reader is referred to <xref target="Attacks-iSec"/>.</t>
</section>
<section title="Attacks on TLS" anchor="sec_Attacks">
<t>
This section lists the attacks that motivated the current recommendations. This is not intended to be an extensive survey of TLS's security.</t>
<t>
While there are widely deployed mitigations for some of the attacks listed below, we believe that their root causes necessitate a more systemic solution.</t>
<section title="SSL Stripping">
<t>
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
<xref target="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) <xref target="RFC6797"/>.
</t>
</section>
<section title="STARTTLS Command Injection Attack (CVE-2011-0411)">
<t>
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.
</t>
</section>
<section title="BEAST (CVE-2011-3389)" anchor="d1e392">
<t>
The BEAST attack <xref target="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.</t>
</section>
<section title="Lucky Thirteen (CVE-2013-0169)" anchor="d1e407">
<t>
A consequence of the MAC-then-encrypt design in all current versions of TLS is the existence of padding oracle attacks <xref target="Padding-Oracle"/>. A recent incarnation of these attacks is the Lucky Thirteen attack <xref target="CBC-Attack"/>, a timing side-channel attack that allows the attacker to decrypt arbitrary ciphertext.</t>
<t>
The Lucky Thirteen attack can be
mitigated by using authenticated encryption like AES-GCM <xref target="RFC5288"/>
or encrypt-then-mac <xref target="I-D.ietf-tls-encrypt-then-mac"/> instead of the TLS default of
MAC-then-encrypt.
</t>
</section>
<section title="Attacks on RC4" anchor="d1e428">
<t>
The RC4 algorithm <xref target="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. <xref target="RC4-Attack-Pau"/>,
<xref target="RC4-Attack-Man"/>, <xref target="RC4-Attack-FMS"/>. Recent cryptanalysis results <xref target="RC4-Attack-AlF"/> exploit biases in
the RC4 keystream to recover repeatedly encrypted plaintexts.
</t>
<t>
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 <xref target="I-D.ietf-tls-prohibiting-rc4"/>.
</t>
</section>
<section title="Compression Attacks: CRIME, TIME and BREACH" anchor="d1e468">
<t>
The CRIME attack <xref target="CRIME"/> (CVE-2012-4929) allows an active attacker to decrypt ciphertext (specifically, cookies) when TLS is used with TLS level compression.</t>
<t>
The TIME attack <xref target="TIME"/> and the later BREACH attack <xref target="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.</t>
<t>
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 <xref target="BREACH"/>). For example, implementations of HTTP that use CSRF tokens will need to randomize them even when the recommendations of <xref target='I-D.ietf-uta-tls-bcp'/> are adopted.</t>
</section>
<section title="Certificate Attacks">
<t>
There have been several practical attacks on TLS when used with RSA certificates (the most common use case).
These include
<xref target="Bleichenbacher98"/> and <xref target="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.
</t>
<t>
The use of RSA certificates often involves exploitable timing issues <xref target="Brumley03"/>
(CVE-2003-0147),
unless the implementation takes
care to explicitly eliminate them.
</t>
<t>
A recent certificate fuzzing tool <xref target="Brubaker2014using"/> uncovered numerous
vulnerabilities in different TLS libraries, related to certificate validation.
</t>
</section>
<section title="Diffie-Hellman Parameters">
<t>
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 <xref target="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 <xref target="RFC6989"/> for the IPsec analogy.
</t>
</section>
<section title="Renegotiation (CVE-2009-3555)">
<t>
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 <xref target="RFC5746"/>.
</t>
</section>
<section title="Triple Handshake (CVE-2014-1295)">
<t>
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 <xref target="RFC5705"/> or "tls-unique"
<xref target="RFC5929"/>.
</t>
</section>
<section title="Virtual Host Confusion">
<t>
A recent article <xref target="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.
</t>
</section>
<section title="Denial of Service">
<t>
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.
</t>
</section>
<section title="Implementation Issues">
<t>
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 <xref target="Georgiev2012"/>.
</t>
<t>
<list style="symbols">
<t>Implementations may omit validation of the server certificate altogether.
For example, this is true of the default implementation of HTTP client libraries
in Python 2 (see e.g. CVE-2013-2191).</t>
<t>Implementations may not validate the server identity. This validation typically amounts
to matching the protocol-level server name with the certificate's Subject
Alternative Name field.
Note: historically, although incorrect, this information is also
often found in the Common Name part of the Distinguished Name
instead.
</t>
<t>Implementations may be validating the certificate chain incorrectly
or not at all, or using an incorrect or outdated trust anchor list.</t>
</list>
</t>
</section>
</section>
<section title="Applicability to DTLS">
<t>
DTLS <xref target="RFC4347"/> <xref target="RFC6347"/> is an adaptation of TLS
for UDP datagrams.
</t>
<t>
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.
</t>
</section>
<section title="Security Considerations" anchor="d1e507">
<t>
This document describes protocol attacks in an informational manner, and in itself does not have any security implications.
Its companion documents certainly do.</t>
</section>
<section title="IANA Considerations" anchor="sec_IANA_Considerations">
<t>This document requires no IANA actions. [Note to RFC Editor: please remove this whole section before publication.]</t>
</section>
<section title="Acknowledgments" anchor="d1e530">
<t>
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.</t>
<t>
The document was prepared using the lyx2rfc tool, created by Nico Williams.</t>
</section>
</middle>
<back>
<references title="Informative References">
<?rfc include="reference.RFC.4347.xml"?>
<?rfc include="reference.RFC.5246.xml"?>
<?rfc include="reference.RFC.5288.xml"?>
<?rfc include="reference.RFC.5705.xml"?>
<?rfc include="reference.RFC.5746.xml"?>
<?rfc include="reference.RFC.5929.xml"?>
<?rfc include="reference.RFC.6347.xml"?>
<?rfc include="reference.RFC.6797.xml"?>
<?rfc include="reference.RFC.6989.xml"?>
<?rfc include="reference.I-D.ietf-uta-tls-bcp.xml"?>
<?rfc include="reference.I-D.ietf-tls-prohibiting-rc4.xml"?>
<?rfc include="reference.I-D.ietf-tls-encrypt-then-mac.xml"?>
<reference anchor="CBC-Attack"><front><title>Lucky Thirteen: Breaking the TLS and DTLS Record Protocols</title><author initials="N.J." surname="AlFardan" fullname="Nadhem J. AlFardan"/><author initials="K." surname="Paterson" fullname="K. Paterson"/><date year="2013"/></front><seriesInfo name="IEEE Symposium on Security and Privacy" value=""/></reference>
<reference anchor="BEAST" target="http://packetstormsecurity.com/files/105499/Browser-Exploit-Against-SSL-TLS.html"><front><title>Browser Exploit Against SSL/TLS</title><author initials="J." surname="Rizzo" fullname="Juliano Rizzo"/><author initials="T." surname="Duong" fullname="Thai Duong"/><date year="2011"/></front></reference>
<reference anchor="CRIME"><front><title>The CRIME Attack</title><author initials="J." surname="Rizzo" fullname="Juliano Rizzo"/><author initials="T." surname="Duong" fullname="Thai Duong"/><date year="2012"/></front><seriesInfo name="EKOparty Security Conference" value="2012"/></reference>
<reference anchor="BREACH" target="http://breachattack.com/"><front><title>The BREACH Attack</title><author initials="A." surname="Prado" fullname="Angelo Prado"/><author initials="N." surname="Harris" fullname="Neal Harris"/><author initials="Y." surname="Gluck" fullname="Yoel Gluck"/><date year="2013"/></front></reference>
<reference anchor="TIME" target="https://media.blackhat.com/eu-13/briefings/Beery/bh-eu-13-a-perfect-crime-beery-wp.pdf"><front><title>A Perfect CRIME? Only TIME Will Tell</title><author initials="T." surname="Be'ery" fullname="Tal Be'ery"/><author initials="A." surname="Shulman" fullname="Amichai Shulman"/><date year="2013"/></front><seriesInfo name="Black Hat Europe" value="2013"/></reference>
<reference anchor="RC4"><front><title>Applied Cryptography: Protocols, Algorithms, and Source Code in C, 2nd Ed.</title><author initials="B." surname="Schneier" fullname="Bruce Schneier"/><date year="1996"/></front></reference>
<reference anchor="RC4-Attack-FMS"><front><title>Weaknesses in the Key Scheduling Algorithm of RC4</title><author initials="S." surname="Fluhrer" fullname="Scott Fluhrer"/><author initials="I." surname="Mantin" fullname="Itsik Mantin"/><author initials="A." surname="Shamir" fullname="Adi Shamir"/><date year="2001"/></front><seriesInfo name="Selected Areas in Cryptography" value=""/></reference>
<reference anchor="RC4-Attack-AlF" target="https://www.usenix.org/conference/usenixsecurity13/security-rc4-tls"><front><title>On the Security of RC4 in TLS</title><author initials="N." surname="AlFardan" fullname="Nadhem AlFardan"/><author initials="D.J." surname="Bernstein" fullname="Daniel J. Bernstein"/><author initials="K.G." surname="Paterson" fullname="Kenneth G. Paterson"/><author initials="B." surname="Poettering" fullname="Bertram Poettering"/><author initials="J.C.N." surname="Schuldt" fullname="Jacob C. N. Schuldt"/><date year="2013"/></front><seriesInfo name="Usenix Security Symposium" value="2013"/></reference>
<reference anchor="Georgiev2012" target="http://doi.acm.org/10.1145/2382196.2382204"><front><title>The most dangerous code in the world: validating SSL certificates in non-browser software</title><author fullname="Martin Georgiev" initials="M." surname="Georgiev" /><author fullname="Subodh Iyengar" initials="S." surname="Iyengar" /><author fullname="Suman Jana" initials="S." surname="Jana" /><author fullname="Rishita Anubhai" initials="R." surname="Anubhai" /><author fullname="Dan Boneh" initials="D." surname="Boneh" /><author fullname="Vitaly Shmatikov" initials="V." surname="Shmatikov" /><date year="2012" /><keyword>https</keyword><keyword> public-key certificates</keyword><keyword> public-key infrastructure</keyword><keyword> security vulnerabilities</keyword><keyword> ssl</keyword><keyword> tls</keyword></front></reference>
<reference anchor="Attacks-iSec" target="https://www.isecpartners.com/media/106031/ssl_attacks_survey.pdf"><front><title>Attacks on SSL, a comprehensive study of BEAST, CRIME, TIME, BREACH, Lucky13 and RC4 biases</title><author initials="P.G." surname="Sarkar" fullname="Pratik Guha Sarkar"/><author initials="S." surname="Fitzgerald" fullname="Shawn Fitzgerald"/><date month="8" year="2013"/></front></reference>
<reference anchor="Padding-Oracle" target="http://www.iacr.org/cryptodb/archive/2002/EUROCRYPT/2850/2850.pdf"><front><title>Security Flaws Induced by CBC Padding Applications to SSL, IPSEC, WTLS...</title><author initials="S." surname="Vaudenay" fullname="Serge Vaudenay"/><date year="2002"/></front><seriesInfo name="EUROCRYPT" value="2002"/></reference>
<reference anchor="Cross-Protocol" target="http://doi.acm.org/10.1145/2382196.2382206"><front><title>A cross-protocol attack on the TLS protocol</title><author fullname="Nikos Mavrogiannopoulos" initials="N." surname="Mavrogiannopoulos" /><author fullname="Frederik Vercauteren" initials="F." surname="Vercauteren" /><author fullname="Vesselin Velichkov" initials="V." surname="Velichkov" /><author fullname="Bart Preneel" initials="B." surname="Preneel" /><date year="2012" /><keyword>cross-protocol attack</keyword><keyword> man-in-the-middle</keyword><keyword> server impersonation attack</keyword><keyword> ssl</keyword><keyword> tls</keyword></front></reference>
<reference anchor="RC4-Attack-Pau" target="http://dblp.uni-trier.de/db/conf/sacrypt/sacrypt2007.html#PaulM07"><front><title>Permutation after RC4 key scheduling reveals the secret key.</title><author fullname="Goutam Paul" initials="G." surname="Paul" /><author fullname="Subhamoy Maitra" initials="S." surname="Maitra" /><date year="2007" /><keyword>dblp</keyword></front></reference>
<reference anchor="RC4-Attack-Man"><front><title>A practical attack on broadcast RC4</title><author fullname="Itsik Mantin" initials="I." surname="Mantin" /><author fullname="Adi Shamir" initials="A." surname="Shamir" /><date year="2001" /></front></reference>
<reference anchor="SSL-Stripping" target="http://www.thoughtcrime.org/software/sslstrip/"><front><title>SSL Stripping</title><author initials="M." surname="Marlinspike" fullname="Moxie Marlinspike"><organization/></author><date year="2009" month="February"/></front></reference>
<reference anchor="Bleichenbacher98"><front><title>Chosen ciphertext attacks against protocols based on the RSA encryption standard pkcs1</title><author fullname="Daniel Bleichenbacher" initials="D." surname="Bleichenbacher" /><date year="1998" /></front></reference>
<reference anchor="Klima03"><front><title>Attacking RSA-based sessions in SSL/TLS</title><author fullname="Vlastimil Klima" initials="V." surname="Klima" /><author fullname="Ondej Pokorny" initials="O." surname="Pokorny" /><author fullname="Tomas Rosa" initials="T." surname="Rosa" /><date year="2003" /></front></reference>
<reference anchor="Brumley03"><front><title>Remote timing attacks are practical</title><author fullname="David Brumley" initials="D." surname="Brumley" /><author fullname="Dan Boneh" initials="D." surname="Boneh" /><date year="2003" /></front></reference>
<reference anchor="Brubaker2014using"><front><title>Using frankencerts for automated adversarial testing of certificate validation in SSL/TLS implementations</title><author fullname="Chad Brubaker" initials="C." surname="Brubaker" /><author fullname="Suman Jana" initials="S." surname="Jana" /><author fullname="Baishakhi Ray" initials="B." surname="Ray" /><author fullname="Sarfraz Khurshid" initials="S." surname="Khurshid" /><author fullname="Vitaly Shmatikov" initials="V." surname="Shmatikov" /><date year="2014" /></front></reference>
<reference anchor="Delignat14"><front><title>Virtual Host Confusion: Weaknesses and Exploits</title><author fullname="Antoine Delignat-Lavaud" initials="A." surname="Delignat-Lavaud" /><author fullname="Karthikeyan Bhargavan" initials="K." surname="Bhargavan" /><date year="2014"/></front><seriesInfo name="Black Hat" value="2014"/></reference>
</references>
<section title="Appendix: Change Log" anchor="changes">
<t>
Note to RFC Editor: please remove this section before publication.</t>
<section title="draft-ietf-uta-tls-attacks-03" anchor="changes-03">
<t>
<list style='symbols'>
<t>Implemented WG Last Call comments.</t>
<t>Virtual host confusion.</t>
<t>STARTTLS command injection.</t>
<t>Added CVE numbers.</t>
</list>
</t>
</section>
<section title="draft-ietf-uta-tls-attacks-02" anchor="changes-02">
<t>
<list style='symbols'>
<t>Added implementation issues ("most dangerous code"), renegotiation,
triple handshake.</t>
<t>Added text re: mitigation of Lucky13.</t>
<t>Added applicability to DTLS.</t>
</list>
</t>
</section>
<section title="draft-ietf-uta-tls-attacks-01" anchor="changes-01">
<t>
<list style='symbols'>
<t>Added SSL Stripping, attacks related to certificates, Diffie Hellman parameters and denial of service.</t>
<t>Expanded on RC4 attacks, thanks to Andrei Popov.</t>
</list>
</t>
</section>
<section title="draft-ietf-uta-tls-attacks-00" anchor="changes-pre">
<t>
<list style='symbols'>
<t>Initial version, extracted from draft-sheffer-tls-bcp-01.</t>
</list>
</t>
</section>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 02:54:40 |