One document matched: draft-ietf-uta-tls-attacks-02.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-02" 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 accesses a Web server using a mixture of HTTP and HTTPS.
      </t>
      </section>
      <section title="BEAST" 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" 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"/>
   and 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 refered to <xref target="I-D.ietf-tls-prohibiting-rc4"/>.
</t>
      </section>
      <section title="Compression Attacks: CRIME and BREACH" anchor="d1e468">
        <t>
The CRIME attack <xref target="CRIME"/> 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"/> 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"/>, unless the implementation takes 
      care to explicitly eliminate them.
      </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 outstanding 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">
      <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 Hanshake">
      <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="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.</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.</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.</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.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>
    </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-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-20262026-04-24 02:55:18