draft-ietf-uta-tls-attacks-04.txt   draft-ietf-uta-tls-attacks-05.txt 
uta Y. Sheffer uta Y. Sheffer
Internet-Draft Porticor Internet-Draft Porticor
Intended status: Informational R. Holz Intended status: Informational R. Holz
Expires: April 1, 2015 TUM Expires: April 26, 2015 TUM
P. Saint-Andre P. Saint-Andre
&yet &yet
September 28, 2014 October 23, 2014
Summarizing Current Attacks on TLS and DTLS Summarizing Known Attacks on TLS and DTLS
draft-ietf-uta-tls-attacks-04 draft-ietf-uta-tls-attacks-05
Abstract Abstract
Over the last few years there have been several serious attacks on Over the last few years there have been several serious attacks on
TLS, including attacks on its most commonly used ciphers and modes of Transport Layer Security (TLS), including attacks on its most
operation. This document summarizes these attacks, with the goal of commonly used ciphers and modes of operation. This document
motivating generic and protocol-specific recommendations on the usage summarizes these attacks, with the goal of motivating generic and
of TLS and DTLS. protocol-specific recommendations on the usage of TLS and Datagram
TLS (DTLS).
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 1, 2015. This Internet-Draft will expire on April 26, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 15 skipping to change at page 2, line 16
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Attacks on TLS . . . . . . . . . . . . . . . . . . . . . . . 3 2. Attacks on TLS . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. SSL Stripping . . . . . . . . . . . . . . . . . . . . . . . 3 2.1. SSL Stripping . . . . . . . . . . . . . . . . . . . . . . . 3
2.2. STARTTLS Command Injection Attack (CVE-2011-0411) . . . . . 3 2.2. STARTTLS Command Injection Attack (CVE-2011-0411) . . . . . 3
2.3. BEAST (CVE-2011-3389) . . . . . . . . . . . . . . . . . . . 4 2.3. BEAST (CVE-2011-3389) . . . . . . . . . . . . . . . . . . . 4
2.4. Lucky Thirteen (CVE-2013-0169) . . . . . . . . . . . . . . 4 2.4. Padding Oracle Attacks . . . . . . . . . . . . . . . . . . 4
2.5. Attacks on RC4 . . . . . . . . . . . . . . . . . . . . . . 4 2.5. Attacks on RC4 . . . . . . . . . . . . . . . . . . . . . . 4
2.6. Compression Attacks: CRIME, TIME and BREACH . . . . . . . . 4 2.6. Compression Attacks: CRIME, TIME and BREACH . . . . . . . . 5
2.7. Certificate Attacks . . . . . . . . . . . . . . . . . . . . 5 2.7. Certificate and RSA-Related Attacks . . . . . . . . . . . . 5
2.8. Diffie-Hellman Parameters . . . . . . . . . . . . . . . . . 5 2.8. Theft of RSA Private Keys . . . . . . . . . . . . . . . . . 6
2.9. Renegotiation (CVE-2009-3555) . . . . . . . . . . . . . . . 5 2.9. Diffie-Hellman Parameters . . . . . . . . . . . . . . . . . 6
2.10. Triple Handshake (CVE-2014-1295) . . . . . . . . . . . . . 5 2.10. Renegotiation (CVE-2009-3555) . . . . . . . . . . . . . . . 6
2.11. Virtual Host Confusion . . . . . . . . . . . . . . . . . . 6 2.11. Triple Handshake (CVE-2014-1295) . . . . . . . . . . . . . 6
2.12. Denial of Service . . . . . . . . . . . . . . . . . . . . . 6 2.12. Virtual Host Confusion . . . . . . . . . . . . . . . . . . 7
2.13. Implementation Issues . . . . . . . . . . . . . . . . . . . 6 2.13. Denial of Service . . . . . . . . . . . . . . . . . . . . . 7
3. Applicability to DTLS . . . . . . . . . . . . . . . . . . . . 7 2.14. Implementation Issues . . . . . . . . . . . . . . . . . . . 7
4. Security Considerations . . . . . . . . . . . . . . . . . . . 7 2.15. Usability . . . . . . . . . . . . . . . . . . . . . . . . . 8
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 3. Applicability to DTLS . . . . . . . . . . . . . . . . . . . . 8
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
7. Informative References . . . . . . . . . . . . . . . . . . . 7 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8
Appendix A. Appendix: Change Log . . . . . . . . . . . . . . . . 10 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8
A.1. draft-ietf-uta-tls-attacks-04 . . . . . . . . . . . . . . . 10 7. Informative References . . . . . . . . . . . . . . . . . . . 9
A.2. draft-ietf-uta-tls-attacks-03 . . . . . . . . . . . . . . . 10 Appendix A. Appendix: Change Log . . . . . . . . . . . . . . . . 12
A.3. draft-ietf-uta-tls-attacks-02 . . . . . . . . . . . . . . . 11 A.1. draft-ietf-uta-tls-attacks-05 . . . . . . . . . . . . . . . 13
A.4. draft-ietf-uta-tls-attacks-01 . . . . . . . . . . . . . . . 11 A.2. draft-ietf-uta-tls-attacks-04 . . . . . . . . . . . . . . . 13
A.5. draft-ietf-uta-tls-attacks-00 . . . . . . . . . . . . . . . 11 A.3. draft-ietf-uta-tls-attacks-03 . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 A.4. draft-ietf-uta-tls-attacks-02 . . . . . . . . . . . . . . . 13
A.5. draft-ietf-uta-tls-attacks-01 . . . . . . . . . . . . . . . 13
A.6. draft-ietf-uta-tls-attacks-00 . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13
1. Introduction 1. Introduction
Over the last few years there have been several major attacks on TLS Over the last few years there have been several major attacks on
[RFC5246], including attacks on its most commonly used ciphers and Transport Layer Security (TLS) [RFC5246], including attacks on its
modes of operation. Details are given in Section 2, but suffice it most commonly used ciphers and modes of operation. Details are given
to say that both AES-CBC and RC4, which together make up for most in Section 2, but a quick summary is that both AES-CBC and RC4, which
current usage, have been seriously attacked in the context of TLS. together make up for most current usage, have been seriously attacked
in the context of TLS.
This situation was one of the motivations for the creation of the UTA This situation was one of the motivations for the creation of the UTA
working group, which is tasked with the creation of generic and working group, which was tasked with the creation of generic and
protocol-specific recommendations for the use of TLS and DTLS. protocol-specific recommendations for the use of TLS along with
Datagram TLS (DTLS) [RFC6347] (unless otherwise noted under
Section 3, all of the information provided in this document applies
to DTLS).
"Attacks always get better; they never get worse" (ironically, this "Attacks always get better; they never get worse" (ironically, this
saying is attributed to the NSA). This list of attacks describes our saying is attributed to the U.S. National Security Agency, the NSA).
knowledge as of this writing. It seems likely that new attacks will This attacks summarized in this document reflect our knowledge as of
be invented in the future. this writing. It seems likely that new attacks will be discovered in
the future.
For a more detailed discussion of the attacks listed here, the For a more detailed discussion of the attacks listed here, the
interested reader is referred to [Attacks-iSec]. interested reader is referred to [Attacks-iSec].
2. Attacks on TLS 2. Attacks on TLS
This section lists the attacks that motivated the current This section lists the attacks that motivated the current
recommendations. This is not intended to be an extensive survey of recommendations in [I-D.ietf-uta-tls-bcp]. This list is not intended
TLS's security. to be an extensive survey of the security of TLS.
While there are widely deployed mitigations for some of the attacks While there are widely deployed mitigations for some of the attacks
listed below, we believe that their root causes necessitate a more listed below, we believe that their root causes necessitate a more
systemic solution. systematic solution, which we have attempted to develop in
[I-D.ietf-uta-tls-bcp].
When such an identifier exists for an attack, we have included its When an identifier exists for an attack, we have included its CVE
CVE (Common Vulnerabilities and Exposures) ID. CVE [CVE] is an (Common Vulnerabilities and Exposures) ID. CVE [CVE] is an
extensive, industry-wide database of software vulnerabilities. extensive, industry-wide database of software vulnerabilities.
2.1. SSL Stripping 2.1. SSL Stripping
Various attacks attempt to remove the use of SSL/TLS altogether, by Various attacks attempt to remove the use of SSL/TLS altogether, by
modifying unencrypted protocols that request the use of TLS, modifying unencrypted protocols that request the use of TLS,
specifically modifying HTTP traffic and HTML pages as they pass on specifically modifying HTTP traffic and HTML pages as they pass on
the wire. These attacks are known collectively as SSL Stripping and the wire. These attacks are known collectively as SSL Stripping (a
were first introduced by Moxie Marlinspike [SSL-Stripping]. In the form of the more generic "downgrade attack") and were first
context of Web traffic, these attacks are only effective if the introduced by Moxie Marlinspike [SSL-Stripping]. In the context of
client initially accesses a Web server using HTTP. A commonly used Web traffic, these attacks are only effective if the client initially
mitigation is HTTP Strict Transport Security (HSTS) [RFC6797]. accesses a Web server using HTTP. A commonly used mitigation is HTTP
Strict Transport Security (HSTS) [RFC6797].
2.2. STARTTLS Command Injection Attack (CVE-2011-0411) 2.2. STARTTLS Command Injection Attack (CVE-2011-0411)
Similarly, there are attacks on the transition between unprotected Similarly, there are attacks on the transition between unprotected
and TLS-protected traffic. A number of IETF application protocols and TLS-protected traffic. A number of IETF application protocols
have used an application-level command, usually STARTTLS, to upgrade have used an application-level command, usually STARTTLS, to upgrade
a clear-text connection to use TLS. Multiple implementations of a clear-text connection to use TLS. Multiple implementations of
STARTTLS had a flaw where an application-layer input buffer retained STARTTLS had a flaw where an application-layer input buffer retained
commands that were pipelined with the STARTTLS command, such that commands that were pipelined with the STARTTLS command, such that
commands received prior to TLS negotiation are executed after TLS commands received prior to TLS negotiation are executed after TLS
negotiation. This problem is resolved by requiring the application- negotiation. This problem is resolved by requiring the application-
level command input buffer to be empty before negotiating TLS. Note level command input buffer to be empty before negotiating TLS. Note
that this flaw lives in the application layer code and does not that this flaw lives in the application layer code and does not
impact the TLS protocol directly. impact the TLS protocol directly.
STARTLS and similar mechanisms are vulnerable to downgrade attacks
whereby the attacker simply removes the STARTTLS indication from the
(unprotected) request. This cannot be mitigated unless HSTS-like
solutions are added.
2.3. BEAST (CVE-2011-3389) 2.3. BEAST (CVE-2011-3389)
The BEAST attack [BEAST] uses issues with the TLS 1.0 implementation The BEAST attack [BEAST] uses issues with the TLS 1.0 implementation
of CBC (that is, the predictable initialization vector) to decrypt of CBC (that is, the predictable initialization vector) to decrypt
parts of a packet, and specifically to decrypt HTTP cookies when HTTP parts of a packet, and specifically to decrypt HTTP cookies when HTTP
is run over TLS. is run over TLS.
2.4. Lucky Thirteen (CVE-2013-0169) 2.4. Padding Oracle Attacks
A consequence of the MAC-then-encrypt design in all current versions A consequence of the MAC-then-encrypt design in all current versions
of TLS is the existence of padding oracle attacks [Padding-Oracle]. of TLS is the existence of padding oracle attacks [Padding-Oracle].
A recent incarnation of these attacks is the Lucky Thirteen attack A recent incarnation of these attacks is the Lucky Thirteen attack
[CBC-Attack], a timing side-channel attack that allows the attacker (CVE-2013-0169) [CBC-Attack], a timing side-channel attack that
to decrypt arbitrary ciphertext. allows the attacker to decrypt arbitrary ciphertext.
The Lucky Thirteen attack can be mitigated by using authenticated The Lucky Thirteen attack can be mitigated by using authenticated
encryption like AES-GCM [RFC5288] or encrypt-then-mac encryption like AES-GCM [RFC5288] or encrypt-then-mac
[I-D.ietf-tls-encrypt-then-mac] instead of the TLS default of MAC- [I-D.ietf-tls-encrypt-then-mac] instead of the TLS default of MAC-
then-encrypt. then-encrypt.
An even newer variant of the padding oracle attack, one that does not
use timing information, is the POODLE attack (CVE-2014-3566) [POODLE]
on SSL 3.0. This attack has no known mitigation.
2.5. Attacks on RC4 2.5. Attacks on RC4
The RC4 algorithm [RC4] has been used with TLS (and previously, SSL) 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 for many years. RC4 has long been known to have a variety of
cryptographic weaknesses, e.g. [RC4-Attack-Pau], [RC4-Attack-Man], cryptographic weaknesses, e.g. [RC4-Attack-Pau], [RC4-Attack-Man],
[RC4-Attack-FMS]. Recent cryptanalysis results [RC4-Attack-AlF] [RC4-Attack-FMS]. Recent cryptanalysis results [RC4-Attack-AlF]
exploit biases in the RC4 keystream to recover repeatedly encrypted exploit biases in the RC4 keystream to recover repeatedly encrypted
plaintexts. plaintexts.
These recent results are on the verge of becoming practically These recent results are on the verge of becoming practically
exploitable; currently they require 2^26 sessions or 13x2^30 exploitable; currently they require 2^26 sessions or 13x2^30
encryptions. As a result, RC4 can no longer be seen as providing a encryptions. As a result, RC4 can no longer be seen as providing a
sufficient level of security for TLS sessions. For further details, sufficient level of security for TLS sessions. For further details,
the reader is referred to [I-D.ietf-tls-prohibiting-rc4]. the reader is referred to [I-D.ietf-tls-prohibiting-rc4] and the
references it cites.
2.6. Compression Attacks: CRIME, TIME and BREACH 2.6. Compression Attacks: CRIME, TIME and BREACH
The CRIME attack [CRIME] (CVE-2012-4929) allows an active attacker to The CRIME attack [CRIME] (CVE-2012-4929) allows an active attacker to
decrypt ciphertext (specifically, cookies) when TLS is used with TLS decrypt ciphertext (specifically, cookies) when TLS is used with TLS
level compression. level compression.
The TIME attack [TIME] and the later BREACH attack [BREACH] The TIME attack [TIME] and the later BREACH attack [BREACH] (CVE-
(CVE-2013-3587, though the number has not been officially allocated) 2013-3587, though the number has not been officially allocated) both
both make similar use of HTTP-level compression to decrypt secret make similar use of HTTP-level compression to decrypt secret data
data passed in the HTTP response. We note that compression of the passed in the HTTP response. We note that compression of the HTTP
HTTP message body is much more prevalent than compression at the TLS message body is much more prevalent than compression at the TLS
level. level.
The former attack can be mitigated by disabling TLS compression. We The former attack can be mitigated by disabling TLS compression. We
are not aware of mitigations at the TLS protocol level to the latter are not aware of mitigations at the TLS protocol level to the latter
attack, and so application-level mitigations are needed (see attack, and so application-level mitigations are needed (see
[BREACH]). For example, implementations of HTTP that use CSRF tokens [BREACH]). For example, implementations of HTTP that use CSRF tokens
will need to randomize them even when the recommendations of will need to randomize them. Even the best practices and
[I-D.ietf-uta-tls-bcp] are adopted. recommendations from [I-D.ietf-uta-tls-bcp] are insufficient to
thwart this attack.
2.7. Certificate Attacks 2.7. Certificate and RSA-Related Attacks
There have been several practical attacks on TLS when used with RSA There have been several practical attacks on TLS when used with RSA
certificates (the most common use case). These include certificates (the most common use case). These include
[Bleichenbacher98] and [Klima03]. While the Bleichenbacher attack [Bleichenbacher98] and [Klima03]. While the Bleichenbacher attack
has been mitigated in TLS 1.0, the Klima attack that relies on a has been mitigated in TLS 1.0, the Klima attack relies on a version-
version-check oracle is only mitigated by TLS 1.1. check oracle is only mitigated by TLS 1.1.
The use of RSA certificates often involves exploitable timing issues The use of RSA certificates often involves exploitable timing issues
[Brumley03] (CVE-2003-0147), unless the implementation takes care to [Brumley03] (CVE-2003-0147), unless the implementation takes care to
explicitly eliminate them. explicitly eliminate them.
A recent certificate fuzzing tool [Brubaker2014using] uncovered A recent certificate fuzzing tool [Brubaker2014using] uncovered
numerous vulnerabilities in different TLS libraries, related to numerous vulnerabilities in different TLS libraries, related to
certificate validation. certificate validation.
2.8. Diffie-Hellman Parameters 2.8. Theft of RSA Private Keys
When TLS is used with most non-Diffie Hellman cipher suites, it is
sufficient to obtain the server's private key in order to decrypt any
sessions (past and future) that were initiated with that server.
This technique is used, for example, by the popular Wireshark network
sniffer to inspect TLS-protected connections.
It is known that stolen (or otherwise obtained) private keys have
been used as part of large-scale monitoring [RFC7258] of certain
servers.
Such attacks can be mitigated by better protecting the private key,
e.g. using OS protections or dedicated hardware. Even more effective
is the use of cipher suites that offer "forward secrecy", the
property that revealing a secret such as a private key does not
expose past or future sessions to a passive attacker.
2.9. Diffie-Hellman Parameters
TLS allows the definition of ephemeral Diffie-Hellman and Elliptic TLS allows the definition of ephemeral Diffie-Hellman and Elliptic
Curve Diffie-Hellman parameters in its respective key exchange modes. Curve Diffie-Hellman parameters in its respective key exchange modes.
This results in an attack detailed in [Cross-Protocol]. In addition, This results in an attack detailed in [Cross-Protocol]. Using
clients that do not properly verify the received parameters are predefined DH groups, as proposed in
exposed to man in the middle (MITM) attacks. Unfortunately the TLS [I-D.ietf-tls-negotiated-ff-dhe], would mitigate this attack.
protocol does not require this verification, see [RFC6989] for the
IPsec analogy.
2.9. Renegotiation (CVE-2009-3555) 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 mandate this verification
(see [RFC6989] for analogous information for IPsec).
2.10. Renegotiation (CVE-2009-3555)
A major attack on the TLS renegotiation mechanism applies to all A major attack on the TLS renegotiation mechanism applies to all
current versions of the protocol. The attack and the TLS extension current versions of the protocol. The attack and the TLS extension
that resolves it are described in [RFC5746]. that resolves it are described in [RFC5746].
2.10. Triple Handshake (CVE-2014-1295) 2.11. Triple Handshake (CVE-2014-1295)
The triple handshake attack [[TRIPLE-HS, add the reference when The triple handshake attack [BhargavanDFPS14] enables the attacker to
published]] enables the attacker to cause two TLS connections to cause two TLS connections to share keying material. This leads to a
share keying material. This leads to a multitude of attacks, e.g. multitude of attacks, e.g. Man-in-the-Middle, breaking safe
Man-in-the-Middle, breaking safe renegotiation and breaking channel renegotiation, and breaking channel binding via TLS Exporter
binding via TLS Exporter [RFC5705] or "tls-unique" [RFC5929]. [RFC5705] or "tls-unique" [RFC5929].
2.11. Virtual Host Confusion 2.12. Virtual Host Confusion
A recent article [Delignat14] describes a security issue whereby A recent article [Delignat14] describes a security issue whereby
SSLv3 fallback and improper handling of session caches on the server SSLv3 fallback and improper handling of session caches on the server
side can be abused by an attacker to establish a malicious connection side can be abused by an attacker to establish a malicious connection
to a virtual host other than originally intended and approved by the to a virtual host other than the one originally intended and approved
server. This attack is especially serious in performance critical by the server. This attack is especially serious in performance
environments where sharing of SSLv3 session caches is very common. critical environments where sharing of SSLv3 session caches is very
common.
2.12. Denial of Service 2.13. Denial of Service
Server CPU power has progressed over the years so that TLS can now be 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 turned on by default. However, the risk of malicious clients and
coordinated groups of clients ("botnets") mounting denial of service coordinated groups of clients ("botnets") mounting denial of service
attacks is still very real. TLS adds another vector for attacks is still very real. TLS adds another vector for
computational attacks, since a client can easily (with little computational attacks, since a client can easily (with little
computational effort) force the server to expend relatively large computational effort) force the server to expend relatively large
computational work. It is known that such attacks have in fact been computational work. It is known that such attacks have in fact been
mounted. mounted.
2.13. Implementation Issues 2.14. Implementation Issues
Even when the protocol is fully specified, there are very common Even when the protocol is properly specified, this does not guarantee
issues that often plague implementations. In particular, when the security of implementations. In fact there are very common
issues that often plague TLS implementations. In particular, when
integrating into higher-level protocols, TLS and its PKI-based integrating into higher-level protocols, TLS and its PKI-based
authentication are sometimes the source of misunderstandings and authentication are sometimes the source of misunderstandings and
implementation "shortcuts". An extensive survey of these issues can implementation "shortcuts". An extensive survey of these issues can
be found in [Georgiev2012]. be found in [Georgiev2012].
o Implementations may omit validation of the server certificate o Implementations might omit validation of the server certificate
altogether. For example, this is true of the default altogether. For example, this is true of the default
implementation of HTTP client libraries in Python 2 (see e.g. implementation of HTTP client libraries in Python 2 (see e.g.
CVE-2013-2191). CVE-2013-2191).
o Implementations may not validate the server identity. This o Implementations might not validate the server identity. This
validation typically amounts to matching the protocol-level server validation typically amounts to matching the protocol-level server
name with the certificate's Subject Alternative Name field. Note: name with the certificate's Subject Alternative Name field. Note:
historically, although incorrect, this information is also often this same information is often also found in the Common Name part
found in the Common Name part of the Distinguished Name instead. of the Distinguished Name, and some validators incorrectly
retrieve it from there instead of from the Subject Alternative
Name.
o Implementations may be validating the certificate chain o Implementations might validate the certificate chain incorrectly
incorrectly or not at all, or using an incorrect or outdated trust or not at all, or use an incorrect or outdated trust anchor list.
anchor list.
An implementation attack of a different kind, one that exploits a
simple coding mistake (bounds check), is the Heartbleed attack (CVE-
2014-0160) that affected a wide swath of the Internet when it was
discovered in April 2014.
2.15. Usability
Many TLS endpoints, such as browsers and mail clients, allow the user
to explicitly accept an invalid server certificate. This often takes
the form of a UI dialog (e.g., "do you accept this server?") and
users have been conditioned to respond in the affirmative in order to
allow the connection to take place.
This user behavior is used by (arguably legitimate) "SSL proxies"
that decrypt and re-encrypt the TLS connection in order to enforce
local security policy. It is also abused by attackers whose goal is
to gain access to the encrypted information.
Mitigation is complex and will probably involve a combination of
protocol mechanisms (HSTS, certificate pinning
[I-D.ietf-websec-key-pinning]) and very careful UI design.
3. Applicability to DTLS 3. Applicability to DTLS
DTLS [RFC4347] [RFC6347] is an adaptation of TLS for UDP datagrams. DTLS [RFC4347] [RFC6347] is an adaptation of TLS for UDP.
With respect to the attacks described in the current document, DTLS 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 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. disallowed in DTLS. DTLS 1.2 is equivalent to TLS 1.2.
4. Security Considerations 4. IANA Considerations
This document describes protocol attacks in an informational manner,
and in itself does not have any security implications. Its companion
documents certainly do.
5. IANA Considerations
This document requires no IANA actions. [Note to RFC Editor: please This document requires no IANA actions. [Note to RFC Editor: please
remove this whole section before publication.] remove this whole section before publication.]
5. Security Considerations
This document describes protocol attacks in an informational manner,
and in itself does not have any security implications. Its companion
documents, especially [I-D.ietf-uta-tls-bcp], certainly do.
6. Acknowledgments 6. Acknowledgments
We would like to thank Stephen Farrell, Simon Josefsson, John We would like to thank Stephen Farrell, Simon Josefsson, John
Mattsson, Yoav Nir, Kenny Paterson, Patrick Pelletier, Tom Ritter and Mattsson, Yoav Nir, Kenny Paterson, Patrick Pelletier, Tom Ritter,
Rich Salz for their review of this document. We thank Andrei Popov Rich Salz and Meral Shirazipour for their feedback on this document.
for contributing text on RC4, Kohei Kasamatsu for text on Lucky13, We thank Andrei Popov for contributing text on RC4, Kohei Kasamatsu
Ilari Liusvaara for text on attacks and on DTLS, Aaron Zauner for for text on Lucky13, Ilari Liusvaara for text on attacks and on DTLS,
text on virtual host confusion, Chris Newman for text on STARTTLS Aaron Zauner for text on virtual host confusion, and Chris Newman for
command injection. text on STARTTLS command injection.
During IESG review, Richard Barnes, Barry Leiba, and Kathleen
Moriarty caught several issues that needed to be addressed.
The authors gratefully acknowledge the assistance of Leif Johansson
and Orit Levin as the working group chairs and Pete Resnick as the
sponsoring Area Director.
The document was prepared using the lyx2rfc tool, created by Nico The document was prepared using the lyx2rfc tool, created by Nico
Williams. Williams.
7. Informative References 7. Informative References
[RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer [RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security", RFC 4347, April 2006. Security", RFC 4347, April 2006.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
skipping to change at page 8, line 22 skipping to change at page 9, line 49
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security Version 1.2", RFC 6347, January 2012. Security Version 1.2", RFC 6347, January 2012.
[RFC6797] Hodges, J., Jackson, C., and A. Barth, "HTTP Strict [RFC6797] Hodges, J., Jackson, C., and A. Barth, "HTTP Strict
Transport Security (HSTS)", RFC 6797, November 2012. Transport Security (HSTS)", RFC 6797, November 2012.
[RFC6989] Sheffer, Y. and S. Fluhrer, "Additional Diffie-Hellman [RFC6989] Sheffer, Y. and S. Fluhrer, "Additional Diffie-Hellman
Tests for the Internet Key Exchange Protocol Version 2 Tests for the Internet Key Exchange Protocol Version 2
(IKEv2)", RFC 6989, July 2013. (IKEv2)", RFC 6989, July 2013.
[RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an
Attack", BCP 188, RFC 7258, May 2014.
[I-D.ietf-uta-tls-bcp] [I-D.ietf-uta-tls-bcp]
Sheffer, Y., Holz, R., and P. Saint-Andre, Sheffer, Y., Holz, R., and P. Saint-Andre,
"Recommendations for Secure Use of TLS and DTLS", draft- "Recommendations for Secure Use of TLS and DTLS", draft-
ietf-uta-tls-bcp-01 (work in progress), June 2014. ietf-uta-tls-bcp-05 (work in progress), October 2014.
[I-D.ietf-tls-prohibiting-rc4] [I-D.ietf-tls-prohibiting-rc4]
Popov, A., "Prohibiting RC4 Cipher Suites", draft-ietf- Popov, A., "Prohibiting RC4 Cipher Suites", draft-ietf-
tls-prohibiting-rc4-00 (work in progress), July 2014. tls-prohibiting-rc4-00 (work in progress), July 2014.
[I-D.ietf-tls-encrypt-then-mac] [I-D.ietf-tls-encrypt-then-mac]
Gutmann, P., "Encrypt-then-MAC for TLS and DTLS", draft- Gutmann, P., "Encrypt-then-MAC for TLS and DTLS", draft-
ietf-tls-encrypt-then-mac-03 (work in progress), July ietf-tls-encrypt-then-mac-03 (work in progress), July
2014. 2014.
[I-D.ietf-tls-negotiated-ff-dhe]
Gillmor, D., "Negotiated Finite Field Diffie-Hellman
Ephemeral Parameters for TLS", draft-ietf-tls-negotiated-
ff-dhe-02 (work in progress), October 2014.
[I-D.ietf-websec-key-pinning]
Evans, C., Palmer, C., and R. Sleevi, "Public Key Pinning
Extension for HTTP", draft-ietf-websec-key-pinning-21
(work in progress), October 2014.
[CVE] MITRE, , "Common Vulnerabilities and Exposures", [CVE] MITRE, , "Common Vulnerabilities and Exposures",
<https://cve.mitre.org/>. <https://cve.mitre.org/>.
[CBC-Attack] [CBC-Attack]
AlFardan, N. and K. Paterson, "Lucky Thirteen: Breaking AlFardan, N. and K. Paterson, "Lucky Thirteen: Breaking
the TLS and DTLS Record Protocols", IEEE Symposium on the TLS and DTLS Record Protocols", IEEE Symposium on
Security and Privacy , 2013. Security and Privacy , 2013.
[BEAST] Rizzo, J. and T. Duong, "Browser Exploit Against SSL/TLS", [BEAST] Rizzo, J. and T. Duong, "Browser Exploit Against SSL/TLS",
2011, <http://packetstormsecurity.com/files/105499/ 2011, <http://packetstormsecurity.com/files/105499/
Browser-Exploit-Against-SSL-TLS.html>. Browser-Exploit-Against-SSL-TLS.html>.
[POODLE] Moeller, B., Duong, T., and K. Kotowicz, "This POODLE
Bites:Exploiting the SSL 3.0 Fallback", 2014,
<https://www.openssl.org/~bodo/ssl-poodle.pdf>.
[CRIME] Rizzo, J. and T. Duong, "The CRIME Attack", EKOparty [CRIME] Rizzo, J. and T. Duong, "The CRIME Attack", EKOparty
Security Conference 2012, 2012. Security Conference 2012, 2012.
[BREACH] Prado, A., Harris, N., and Y. Gluck, "The BREACH Attack", [BREACH] Prado, A., Harris, N., and Y. Gluck, "The BREACH Attack",
2013, <http://breachattack.com/>. 2013, <http://breachattack.com/>.
[TIME] Be'ery, T. and A. Shulman, "A Perfect CRIME? Only TIME [TIME] Be'ery, T. and A. Shulman, "A Perfect CRIME? Only TIME
Will Tell", Black Hat Europe 2013, 2013, Will Tell", Black Hat Europe 2013, 2013,
<https://media.blackhat.com/eu-13/briefings/Beery/bh- <https://media.blackhat.com/eu-13/briefings/Beery/bh-eu-
eu-13-a-perfect-crime-beery-wp.pdf>. 13-a-perfect-crime-beery-wp.pdf>.
[RC4] Schneier, B., "Applied Cryptography: Protocols, [RC4] Schneier, B., "Applied Cryptography: Protocols,
Algorithms, and Source Code in C, 2nd Ed.", 1996. Algorithms, and Source Code in C, 2nd Ed.", 1996.
[RC4-Attack-FMS] [RC4-Attack-FMS]
Fluhrer, S., Mantin, I., and A. Shamir, "Weaknesses in the Fluhrer, S., Mantin, I., and A. Shamir, "Weaknesses in the
Key Scheduling Algorithm of RC4", Selected Areas in Key Scheduling Algorithm of RC4", Selected Areas in
Cryptography , 2001. Cryptography , 2001.
[RC4-Attack-AlF] [RC4-Attack-AlF]
AlFardan, N., Bernstein, D., Paterson, K., Poettering, B., AlFardan, N., Bernstein, D., Paterson, K., Poettering, B.,
and J. Schuldt, "On the Security of RC4 in TLS", Usenix and J. Schuldt, "On the Security of RC4 in TLS", Usenix
Security Symposium 2013, 2013, <https://www.usenix.org/ Security Symposium 2013, 2013,
conference/usenixsecurity13/security-rc4-tls>. <https://www.usenix.org/conference/usenixsecurity13/
security-rc4-tls>.
[Georgiev2012] [Georgiev2012]
Georgiev, M., Iyengar, S., Jana, S., Anubhai, R., Boneh, Georgiev, M., Iyengar, S., Jana, S., Anubhai, R., Boneh,
D., and V. Shmatikov, "The most dangerous code in the D., and V. Shmatikov, "The most dangerous code in the
world: validating SSL certificates in non-browser world: validating SSL certificates in non-browser
software", 2012, software", 2012,
<http://doi.acm.org/10.1145/2382196.2382204>. <http://doi.acm.org/10.1145/2382196.2382204>.
[Attacks-iSec] [Attacks-iSec]
Sarkar, P. and S. Fitzgerald, "Attacks on SSL, a Sarkar, P. and S. Fitzgerald, "Attacks on SSL, a
comprehensive study of BEAST, CRIME, TIME, BREACH, Lucky13 comprehensive study of BEAST, CRIME, TIME, BREACH, Lucky13
and RC4 biases", 8 2013, <https://www.isecpartners.com/ and RC4 biases", 8 2013,
media/106031/ssl_attacks_survey.pdf>. <https://www.isecpartners.com/media/106031/
ssl_attacks_survey.pdf>.
[Padding-Oracle] [Padding-Oracle]
Vaudenay, S., "Security Flaws Induced by CBC Padding Vaudenay, S., "Security Flaws Induced by CBC Padding
Applications to SSL, IPSEC, WTLS...", EUROCRYPT 2002, Applications to SSL, IPSEC, WTLS...", EUROCRYPT 2002,
2002, <http://www.iacr.org/cryptodb/archive/2002/ 2002, <http://www.iacr.org/cryptodb/archive/2002/
EUROCRYPT/2850/2850.pdf>. EUROCRYPT/2850/2850.pdf>.
[Cross-Protocol] [Cross-Protocol]
Mavrogiannopoulos, N., Vercauteren, F., Velichkov, V., and Mavrogiannopoulos, N., Vercauteren, F., Velichkov, V., and
B. Preneel, "A cross-protocol attack on the TLS protocol", B. Preneel, "A cross-protocol attack on the TLS protocol",
skipping to change at page 10, line 35 skipping to change at page 12, line 41
[Brubaker2014using] [Brubaker2014using]
Brubaker, C., Jana, S., Ray, B., Khurshid, S., and V. Brubaker, C., Jana, S., Ray, B., Khurshid, S., and V.
Shmatikov, "Using frankencerts for automated adversarial Shmatikov, "Using frankencerts for automated adversarial
testing of certificate validation in SSL/TLS testing of certificate validation in SSL/TLS
implementations", 2014. implementations", 2014.
[Delignat14] [Delignat14]
Delignat-Lavaud, A. and K. Bhargavan, "Virtual Host Delignat-Lavaud, A. and K. Bhargavan, "Virtual Host
Confusion: Weaknesses and Exploits", Black Hat 2014, 2014. Confusion: Weaknesses and Exploits", Black Hat 2014, 2014.
[BhargavanDFPS14]
Bhargavan, K., Delignat-Lavaud, A., Fournet, C., Pironti,
A., and P. Strub, "Triple handshakes and cookie cutters:
breaking and fixing authentication over tls", 2014,
<http://prosecco.gforge.inria.fr/pubs/
triple-handshakes-and-cookie-cutters-sp14.pdf>.
Appendix A. Appendix: Change Log Appendix A. Appendix: Change Log
Note to RFC Editor: please remove this section before publication. Note to RFC Editor: please remove this section before publication.
A.1. draft-ietf-uta-tls-attacks-04 A.1. draft-ietf-uta-tls-attacks-05
o Implemented Gen-ART and IESG reviews.
A.2. draft-ietf-uta-tls-attacks-04
o Implemented AD review comments. o Implemented AD review comments.
A.2. draft-ietf-uta-tls-attacks-03 A.3. draft-ietf-uta-tls-attacks-03
o Implemented WG Last Call comments. o Implemented WG Last Call comments.
o Virtual host confusion. o Virtual host confusion.
o STARTTLS command injection. o STARTTLS command injection.
o Added CVE numbers. o Added CVE numbers.
A.3. draft-ietf-uta-tls-attacks-02 A.4. draft-ietf-uta-tls-attacks-02
o Added implementation issues ("most dangerous code"), o Added implementation issues ("most dangerous code"),
renegotiation, triple handshake. renegotiation, triple handshake.
o Added text re: mitigation of Lucky13. o Added text re: mitigation of Lucky13.
o Added applicability to DTLS. o Added applicability to DTLS.
A.4. draft-ietf-uta-tls-attacks-01 A.5. draft-ietf-uta-tls-attacks-01
o Added SSL Stripping, attacks related to certificates, Diffie o Added SSL Stripping, attacks related to certificates, Diffie
Hellman parameters and denial of service. Hellman parameters and denial of service.
o Expanded on RC4 attacks, thanks to Andrei Popov. o Expanded on RC4 attacks, thanks to Andrei Popov.
A.5. draft-ietf-uta-tls-attacks-00 A.6. draft-ietf-uta-tls-attacks-00
o Initial version, extracted from draft-sheffer-tls-bcp-01. o Initial version, extracted from draft-sheffer-tls-bcp-01.
Authors' Addresses Authors' Addresses
Yaron Sheffer Yaron Sheffer
Porticor Porticor
29 HaHarash St. 29 HaHarash St.
Hod HaSharon 4501303 Hod HaSharon 4501303
Israel Israel
skipping to change at page 11, line 45 skipping to change at page 14, line 14
Ralph Holz Ralph Holz
Technische Universitaet Muenchen Technische Universitaet Muenchen
Boltzmannstr. 3 Boltzmannstr. 3
Garching 85748 Garching 85748
Germany Germany
Email: holz@net.in.tum.de Email: holz@net.in.tum.de
Peter Saint-Andre Peter Saint-Andre
&yet &yet
P.O. Box 787
Parker, CO 80134
USA
Email: peter@andyet.com Email: peter@andyet.com
URI: https://andyet.com/
 End of changes. 58 change blocks. 
123 lines changed or deleted 225 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/