draft-ietf-uta-tls-attacks-05.txt | rfc7457.txt | |||
---|---|---|---|---|
uta Y. Sheffer | Internet Engineering Task Force (IETF) Y. Sheffer | |||
Internet-Draft Porticor | Request for Comments: 7457 Porticor | |||
Intended status: Informational R. Holz | Category: Informational R. Holz | |||
Expires: April 26, 2015 TUM | ISSN: 2070-1721 Technische Universitaet Muenchen | |||
P. Saint-Andre | P. Saint-Andre | |||
&yet | &yet | |||
October 23, 2014 | February 2015 | |||
Summarizing Known Attacks on TLS and DTLS | Summarizing Known Attacks on Transport Layer Security (TLS) | |||
draft-ietf-uta-tls-attacks-05 | and Datagram TLS (DTLS) | |||
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 | |||
Transport Layer Security (TLS), including attacks on its most | Transport Layer Security (TLS), including attacks on its most | |||
commonly used ciphers and modes of operation. This document | commonly used ciphers and modes of operation. This document | |||
summarizes these attacks, with the goal of motivating generic and | summarizes these attacks, with the goal of motivating generic and | |||
protocol-specific recommendations on the usage of TLS and Datagram | protocol-specific recommendations on the usage of TLS and Datagram | |||
TLS (DTLS). | TLS (DTLS). | |||
Status of This Memo | Status of This Memo | |||
This Internet-Draft is submitted in full conformance with the | This document is not an Internet Standards Track specification; it is | |||
provisions of BCP 78 and BCP 79. | published for informational purposes. | |||
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 | This document is a product of the Internet Engineering Task Force | |||
and may be updated, replaced, or obsoleted by other documents at any | (IETF). It represents the consensus of the IETF community. It has | |||
time. It is inappropriate to use Internet-Drafts as reference | received public review and has been approved for publication by the | |||
material or to cite them other than as "work in progress." | Internet Engineering Steering Group (IESG). Not all documents | |||
approved by the IESG are a candidate for any level of Internet | ||||
Standard; see Section 2 of RFC 5741. | ||||
This Internet-Draft will expire on April 26, 2015. | Information about the current status of this document, any errata, | |||
and how to provide feedback on it may be obtained at | ||||
http://www.rfc-editor.org/info/rfc7457. | ||||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2014 IETF Trust and the persons identified as the | Copyright (c) 2015 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 | |||
carefully, as they describe your rights and restrictions with respect | carefully, as they describe your rights and restrictions with respect | |||
to this document. Code Components extracted from this document must | to this document. Code Components extracted from this document must | |||
include Simplified BSD License text as described in Section 4.e of | include Simplified BSD License text as described in Section 4.e of | |||
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 ....................................................3 | ||||
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) ..........4 | |||
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. Padding Oracle Attacks .....................................4 | |||
2.4. Padding Oracle Attacks . . . . . . . . . . . . . . . . . . 4 | 2.5. Attacks on RC4 .............................................5 | |||
2.5. Attacks on RC4 . . . . . . . . . . . . . . . . . . . . . . 4 | 2.6. Compression Attacks: CRIME, TIME, and BREACH ...............5 | |||
2.6. Compression Attacks: CRIME, TIME and BREACH . . . . . . . . 5 | 2.7. Certificate and RSA-Related Attacks ........................5 | |||
2.7. Certificate and RSA-Related Attacks . . . . . . . . . . . . 5 | 2.8. Theft of RSA Private Keys ..................................6 | |||
2.8. Theft of RSA Private Keys . . . . . . . . . . . . . . . . . 6 | 2.9. Diffie-Hellman Parameters ..................................6 | |||
2.9. Diffie-Hellman Parameters . . . . . . . . . . . . . . . . . 6 | 2.10. Renegotiation (CVE-2009-3555) .............................6 | |||
2.10. Renegotiation (CVE-2009-3555) . . . . . . . . . . . . . . . 6 | 2.11. Triple Handshake (CVE-2014-1295) ..........................6 | |||
2.11. Triple Handshake (CVE-2014-1295) . . . . . . . . . . . . . 6 | 2.12. Virtual Host Confusion ....................................7 | |||
2.12. Virtual Host Confusion . . . . . . . . . . . . . . . . . . 7 | 2.13. Denial of Service .........................................7 | |||
2.13. Denial of Service . . . . . . . . . . . . . . . . . . . . . 7 | 2.14. Implementation Issues .....................................7 | |||
2.14. Implementation Issues . . . . . . . . . . . . . . . . . . . 7 | 2.15. Usability .................................................8 | |||
2.15. Usability . . . . . . . . . . . . . . . . . . . . . . . . . 8 | 3. Applicability to DTLS ...........................................8 | |||
3. Applicability to DTLS . . . . . . . . . . . . . . . . . . . . 8 | 4. Security Considerations .........................................8 | |||
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 | 5. Informative References ..........................................8 | |||
5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 | Acknowledgements ..................................................13 | |||
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8 | Authors' Addresses ................................................13 | |||
7. Informative References . . . . . . . . . . . . . . . . . . . 9 | ||||
Appendix A. Appendix: Change Log . . . . . . . . . . . . . . . . 12 | ||||
A.1. draft-ietf-uta-tls-attacks-05 . . . . . . . . . . . . . . . 13 | ||||
A.2. draft-ietf-uta-tls-attacks-04 . . . . . . . . . . . . . . . 13 | ||||
A.3. draft-ietf-uta-tls-attacks-03 . . . . . . . . . . . . . . . 13 | ||||
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 | Over the last few years, there have been several major attacks on TLS | |||
Transport Layer Security (TLS) [RFC5246], including attacks on its | [RFC5246], including attacks on its most commonly used ciphers and | |||
most commonly used ciphers and modes of operation. Details are given | modes of operation. Details are given in Section 2, but a quick | |||
in Section 2, but a quick summary is that both AES-CBC and RC4, which | summary is that both AES-CBC and RC4, which together make up for most | |||
together make up for most current usage, have been seriously attacked | current usage, have been seriously attacked in the context of TLS. | |||
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 was 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 along with | protocol-specific recommendations for the use of TLS and DTLS | |||
Datagram TLS (DTLS) [RFC6347] (unless otherwise noted under | [RFC6347] (unless otherwise noted under Section 3, all of the | |||
Section 3, all of the information provided in this document applies | information provided in this document applies to DTLS). | |||
to DTLS). | ||||
"Attacks always get better; they never get worse" (ironically, this | There is an old saying attributed, ironically enough, to the US | |||
saying is attributed to the U.S. National Security Agency, the NSA). | National Security Agency (NSA): "Attacks always get better; they | |||
This attacks summarized in this document reflect our knowledge as of | never get worse." Unfortunately, that saying is true, so any | |||
this writing. It seems likely that new attacks will be discovered in | description of security attacks can only be a snapshot in time. | |||
the future. | Therefore this document reflects our knowledge as of 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 in [I-D.ietf-uta-tls-bcp]. This list is not intended | recommendations in [SECURE-TLS]. This list is not intended to be an | |||
to be an extensive survey of the security of TLS. | 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 | |||
systematic solution, which we have attempted to develop in | systematic solution, which we have attempted to develop in | |||
[I-D.ietf-uta-tls-bcp]. | [SECURE-TLS]. | |||
When an identifier exists for an attack, we have included its CVE | When an identifier exists for an attack, we have included its Common | |||
(Common Vulnerabilities and Exposures) ID. CVE [CVE] is an | Vulnerabilities and Exposures (CVE) ID. CVE [CVE] is an extensive, | |||
extensive, industry-wide database of software vulnerabilities. | 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 Secure Socket Layer / | |||
modifying unencrypted protocols that request the use of TLS, | Transport Layer Security (SSL/TLS) altogether by modifying | |||
specifically modifying HTTP traffic and HTML pages as they pass on | unencrypted protocols that request the use of TLS, specifically | |||
the wire. These attacks are known collectively as SSL Stripping (a | modifying HTTP traffic and HTML pages as they pass on the wire. | |||
form of the more generic "downgrade attack") and were first | These attacks are known collectively as "SSL Stripping" (a form of | |||
introduced by Moxie Marlinspike [SSL-Stripping]. In the context of | the more generic "downgrade attack") and were first introduced by | |||
Web traffic, these attacks are only effective if the client initially | Moxie Marlinspike [SSL-Stripping]. In the context of Web traffic, | |||
accesses a Web server using HTTP. A commonly used mitigation is HTTP | these attacks are only effective if the client initially accesses a | |||
Strict Transport Security (HSTS) [RFC6797]. | 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 cleartext 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 | STARTTLS and similar mechanisms are vulnerable to downgrade attacks, | |||
whereby the attacker simply removes the STARTTLS indication from the | whereby the attacker simply removes the STARTTLS indication from the | |||
(unprotected) request. This cannot be mitigated unless HSTS-like | (unprotected) request. This cannot be mitigated unless HSTS-like | |||
solutions are added. | 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 Cipher Block Chaining (CBC) (that is, the predictable | |||
parts of a packet, and specifically to decrypt HTTP cookies when HTTP | initialization vector) to decrypt parts of a packet, and specifically | |||
is run over TLS. | to decrypt HTTP cookies when HTTP is run over TLS. | |||
2.4. Padding Oracle Attacks | 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 | |||
(CVE-2013-0169) [CBC-Attack], a timing side-channel attack that | (CVE-2013-0169) [CBC-Attack], a timing side-channel attack that | |||
allows the attacker 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 [RFC7366] | |||
[I-D.ietf-tls-encrypt-then-mac] instead of the TLS default of 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 | An even newer variant of the padding oracle attack, one that does not | |||
use timing information, is the POODLE attack (CVE-2014-3566) [POODLE] | use timing information, is the POODLE attack (CVE-2014-3566) [POODLE] | |||
on SSL 3.0. This attack has no known mitigation. | 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] | and [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] and the | the reader is referred to [CIPHER-SUITES] and the references it | |||
references it cites. | 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] (CVE- | The TIME attack [TIME] and the later BREACH attack [BREACH] (CVE- | |||
2013-3587, though the number has not been officially allocated) both | 2013-3587, though the number has not been officially allocated) both | |||
make similar use of HTTP-level compression to decrypt secret data | make similar use of HTTP-level compression to decrypt secret data | |||
passed in the HTTP response. We note that compression of the HTTP | passed in the HTTP response. We note that compression of the 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 TIME 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 BREACH | |||
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 Cross-Site | |||
will need to randomize them. Even the best practices and | Request Forgery (CSRF) tokens will need to randomize them. Even the | |||
recommendations from [I-D.ietf-uta-tls-bcp] are insufficient to | best practices and recommendations from [SECURE-TLS] are insufficient | |||
thwart this attack. | to thwart this attack. | |||
2.7. Certificate and RSA-Related 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 relies on a version- | has been mitigated in TLS 1.0, the Klima attack, which relies on a | |||
check oracle is only mitigated by TLS 1.1. | version-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. Theft of RSA Private Keys | 2.8. Theft of RSA Private Keys | |||
When TLS is used with most non-Diffie Hellman cipher suites, it is | 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 | sufficient to obtain the server's private key in order to decrypt any | |||
sessions (past and future) that were initiated with that server. | sessions (past and future) that were initiated with that server. | |||
This technique is used, for example, by the popular Wireshark network | This technique is used, for example, by the popular Wireshark network | |||
sniffer to inspect TLS-protected connections. | sniffer to inspect TLS-protected connections. | |||
It is known that stolen (or otherwise obtained) private keys have | It is known that stolen (or otherwise obtained) private keys have | |||
been used as part of large-scale monitoring [RFC7258] of certain | been used as part of large-scale monitoring [RFC7258] of certain | |||
servers. | servers. | |||
Such attacks can be mitigated by better protecting the private key, | Such attacks can be mitigated by better protecting the private key, | |||
e.g. using OS protections or dedicated hardware. Even more effective | e.g., using OS protections or dedicated hardware. Even more | |||
is the use of cipher suites that offer "forward secrecy", the | effective is the use of cipher suites that offer "forward secrecy", | |||
property that revealing a secret such as a private key does not | the property where revealing a secret such as a private key does not | |||
expose past or future sessions to a passive attacker. | expose past or future sessions to a passive attacker. | |||
2.9. Diffie-Hellman Parameters | 2.9. Diffie-Hellman Parameters | |||
TLS allows the definition of ephemeral Diffie-Hellman and Elliptic | TLS allows the definition of ephemeral Diffie-Hellman (DH) and | |||
Curve Diffie-Hellman parameters in its respective key exchange modes. | Elliptic Curve Diffie-Hellman parameters in its respective key | |||
This results in an attack detailed in [Cross-Protocol]. Using | exchange modes. This results in an attack detailed in | |||
predefined DH groups, as proposed in | [Cross-Protocol]. Using predefined DH groups, as proposed in | |||
[I-D.ietf-tls-negotiated-ff-dhe], would mitigate this attack. | [FFDHE-TLS], would mitigate this attack. | |||
In addition, clients that do not properly verify the received | In addition, clients that do not properly verify the received | |||
parameters are exposed to man in the middle (MITM) attacks. | parameters are exposed to man-in-the-middle (MITM) attacks. | |||
Unfortunately the TLS protocol does not mandate this verification | Unfortunately, the TLS protocol does not mandate this verification | |||
(see [RFC6989] for analogous information for IPsec). | (see [RFC6989] for analogous information for IPsec). | |||
2.10. Renegotiation (CVE-2009-3555) | 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.11. Triple Handshake (CVE-2014-1295) | 2.11. Triple Handshake (CVE-2014-1295) | |||
The triple handshake attack [BhargavanDFPS14] enables the attacker to | The triple handshake attack [BhargavanDFPS14] enables the attacker to | |||
cause two TLS connections to share keying material. This leads to a | cause two TLS connections to share keying material. This leads to a | |||
multitude of attacks, e.g. Man-in-the-Middle, breaking safe | multitude of attacks, e.g., man-in-the-middle, breaking safe | |||
renegotiation, and breaking channel binding via TLS Exporter | renegotiation, and breaking channel binding via TLS Exporter | |||
[RFC5705] or "tls-unique" [RFC5929]. | [RFC5705] or "tls-unique" [RFC5929]. | |||
2.12. 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 the one originally intended and approved | to a virtual host other than the one originally intended and approved | |||
by the server. This attack is especially serious in performance | by the server. This attack is especially serious in performance | |||
critical environments where sharing of SSLv3 session caches is very | critical environments where sharing of SSLv3 session caches is very | |||
common. | common. | |||
2.13. 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.14. Implementation Issues | 2.14. Implementation Issues | |||
Even when the protocol is properly specified, this does not guarantee | Even when the protocol is properly specified, this does not guarantee | |||
the security of implementations. In fact there are very common | the security of implementations. In fact, there are very common | |||
issues that often plague TLS implementations. In particular, when | 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 might 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 (e.g., CVE- | |||
CVE-2013-2191). | 2013-2191). | |||
o Implementations might 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: | |||
this same information is often also found in the Common Name part | this same information is often also found in the Common Name part | |||
of the Distinguished Name, and some validators incorrectly | of the Distinguished Name, and some validators incorrectly | |||
retrieve it from there instead of from the Subject Alternative | retrieve it from there instead of from the Subject Alternative | |||
Name. | Name. | |||
o Implementations might validate the certificate chain incorrectly | o Implementations might validate the certificate chain incorrectly | |||
skipping to change at page 8, line 14 | skipping to change at page 8, line 14 | |||
An implementation attack of a different kind, one that exploits a | An implementation attack of a different kind, one that exploits a | |||
simple coding mistake (bounds check), is the Heartbleed attack (CVE- | simple coding mistake (bounds check), is the Heartbleed attack (CVE- | |||
2014-0160) that affected a wide swath of the Internet when it was | 2014-0160) that affected a wide swath of the Internet when it was | |||
discovered in April 2014. | discovered in April 2014. | |||
2.15. Usability | 2.15. Usability | |||
Many TLS endpoints, such as browsers and mail clients, allow the user | Many TLS endpoints, such as browsers and mail clients, allow the user | |||
to explicitly accept an invalid server certificate. This often takes | to explicitly accept an invalid server certificate. This often takes | |||
the form of a UI dialog (e.g., "do you accept this server?") and | 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 | users have been conditioned to respond in the affirmative in order to | |||
allow the connection to take place. | allow the connection to take place. | |||
This user behavior is used by (arguably legitimate) "SSL proxies" | This user behavior is used by (arguably legitimate) "SSL proxies" | |||
that decrypt and re-encrypt the TLS connection in order to enforce | that decrypt and re-encrypt the TLS connection in order to enforce | |||
local security policy. It is also abused by attackers whose goal is | local security policy. It is also abused by attackers whose goal is | |||
to gain access to the encrypted information. | to gain access to the encrypted information. | |||
Mitigation is complex and will probably involve a combination of | Mitigation is complex and will probably involve a combination of | |||
protocol mechanisms (HSTS, certificate pinning | protocol mechanisms (HSTS, certificate pinning [KEY-PINNING]), and | |||
[I-D.ietf-websec-key-pinning]) and very careful UI design. | very careful UI design. | |||
3. Applicability to DTLS | 3. Applicability to DTLS | |||
DTLS [RFC4347] [RFC6347] is an adaptation of TLS for UDP. | 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. IANA Considerations | 4. Security Considerations | |||
This document requires no IANA actions. [Note to RFC Editor: please | ||||
remove this whole section before publication.] | ||||
5. Security Considerations | ||||
This document describes protocol attacks in an informational manner, | This document describes protocol attacks in an informational manner | |||
and in itself does not have any security implications. Its companion | and in itself does not have any security implications. Its companion | |||
documents, especially [I-D.ietf-uta-tls-bcp], certainly do. | documents, especially [SECURE-TLS], certainly do. | |||
6. Acknowledgments | ||||
We would like to thank Stephen Farrell, Simon Josefsson, John | ||||
Mattsson, Yoav Nir, Kenny Paterson, Patrick Pelletier, Tom Ritter, | ||||
Rich Salz and Meral Shirazipour for their feedback on 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, and Chris Newman for | ||||
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 | ||||
Williams. | ||||
7. Informative References | ||||
[RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer | ||||
Security", RFC 4347, April 2006. | ||||
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security | ||||
(TLS) Protocol Version 1.2", RFC 5246, August 2008. | ||||
[RFC5288] Salowey, J., Choudhury, A., and D. McGrew, "AES Galois | ||||
Counter Mode (GCM) Cipher Suites for TLS", RFC 5288, | ||||
August 2008. | ||||
[RFC5705] Rescorla, E., "Keying Material Exporters for Transport | ||||
Layer Security (TLS)", RFC 5705, March 2010. | ||||
[RFC5746] Rescorla, E., Ray, M., Dispensa, S., and N. Oskov, | ||||
"Transport Layer Security (TLS) Renegotiation Indication | ||||
Extension", RFC 5746, February 2010. | ||||
[RFC5929] Altman, J., Williams, N., and L. Zhu, "Channel Bindings | ||||
for TLS", RFC 5929, July 2010. | ||||
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer | ||||
Security Version 1.2", RFC 6347, January 2012. | ||||
[RFC6797] Hodges, J., Jackson, C., and A. Barth, "HTTP Strict | ||||
Transport Security (HSTS)", RFC 6797, November 2012. | ||||
[RFC6989] Sheffer, Y. and S. Fluhrer, "Additional Diffie-Hellman | 5. Informative References | |||
Tests for the Internet Key Exchange Protocol Version 2 | ||||
(IKEv2)", RFC 6989, July 2013. | ||||
[RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an | [Attacks-iSec] | |||
Attack", BCP 188, RFC 7258, May 2014. | Sarkar, P. and S. Fitzgerald, "Attacks on SSL, a | |||
comprehensive study of BEAST, CRIME, TIME, BREACH, Lucky13 | ||||
and RC4 biases", August 2013, | ||||
<https://www.isecpartners.com/media/106031/ | ||||
ssl_attacks_survey.pdf>. | ||||
[I-D.ietf-uta-tls-bcp] | [BEAST] Rizzo, J. and T. Duong, "Browser Exploit Against SSL/TLS", | |||
Sheffer, Y., Holz, R., and P. Saint-Andre, | 2011, <http://packetstormsecurity.com/files/105499/ | |||
"Recommendations for Secure Use of TLS and DTLS", draft- | Browser-Exploit-Against-SSL-TLS.html>. | |||
ietf-uta-tls-bcp-05 (work in progress), October 2014. | ||||
[I-D.ietf-tls-prohibiting-rc4] | [BREACH] Prado, A., Harris, N., and Y. Gluck, "The BREACH Attack", | |||
Popov, A., "Prohibiting RC4 Cipher Suites", draft-ietf- | 2013, <http://breachattack.com/>. | |||
tls-prohibiting-rc4-00 (work in progress), July 2014. | ||||
[I-D.ietf-tls-encrypt-then-mac] | [BhargavanDFPS14] | |||
Gutmann, P., "Encrypt-then-MAC for TLS and DTLS", draft- | Bhargavan, K., Delignat-Lavaud, A., Fournet, C., Pironti, | |||
ietf-tls-encrypt-then-mac-03 (work in progress), July | A., and P. Strub, "Triple handshakes and cookie cutters: | |||
2014. | breaking and fixing authentication over tls", 2014, | |||
<https://secure-resumption.com/tlsauth.pdf>. | ||||
[I-D.ietf-tls-negotiated-ff-dhe] | [Bleichenbacher98] | |||
Gillmor, D., "Negotiated Finite Field Diffie-Hellman | Bleichenbacher, D., "Chosen Ciphertext Attacks Against | |||
Ephemeral Parameters for TLS", draft-ietf-tls-negotiated- | Protocols Based on the RSA Encryption Standard PKCS #1", | |||
ff-dhe-02 (work in progress), October 2014. | 1998, <http://archiv.infsec.ethz.ch/education/fs08/secsem/ | |||
Bleichenbacher98.pdf>. | ||||
[I-D.ietf-websec-key-pinning] | [Brubaker2014using] | |||
Evans, C., Palmer, C., and R. Sleevi, "Public Key Pinning | Brubaker, C., Jana, S., Ray, B., Khurshid, S., and V. | |||
Extension for HTTP", draft-ietf-websec-key-pinning-21 | Shmatikov, "Using Frankencerts for Automated Adversarial | |||
(work in progress), October 2014. | Testing of Certificate Validation in SSL/TLS | |||
Implementations", 2014, | ||||
<https://www.cs.utexas.edu/~shmat/shmat_oak14.pdf>. | ||||
[CVE] MITRE, , "Common Vulnerabilities and Exposures", | [Brumley03] | |||
<https://cve.mitre.org/>. | Brumley, D. and D. Boneh, "Remote Timing Attacks are | |||
Practical", 2003, | ||||
<http://crypto.stanford.edu/~dabo/papers/ssl-timing.pdf>. | ||||
[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, <http://www.ieee-security.org/ | |||
TC/SP2013/papers/4977a526.pdf>. | ||||
[BEAST] Rizzo, J. and T. Duong, "Browser Exploit Against SSL/TLS", | ||||
2011, <http://packetstormsecurity.com/files/105499/ | ||||
Browser-Exploit-Against-SSL-TLS.html>. | ||||
[POODLE] Moeller, B., Duong, T., and K. Kotowicz, "This POODLE | [CIPHER-SUITES] | |||
Bites:Exploiting the SSL 3.0 Fallback", 2014, | Popov, A., "Prohibiting RC4 Cipher Suites", Work in | |||
<https://www.openssl.org/~bodo/ssl-poodle.pdf>. | Progress, draft-ietf-tls-prohibiting-rc4-01, October 2014. | |||
[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. | |||
[BREACH] Prado, A., Harris, N., and Y. Gluck, "The BREACH Attack", | ||||
2013, <http://breachattack.com/>. | ||||
[TIME] Be'ery, T. and A. Shulman, "A Perfect CRIME? Only TIME | [CVE] MITRE, "Common Vulnerabilities and Exposures", | |||
Will Tell", Black Hat Europe 2013, 2013, | <https://cve.mitre.org/>. | |||
<https://media.blackhat.com/eu-13/briefings/Beery/bh-eu- | ||||
13-a-perfect-crime-beery-wp.pdf>. | ||||
[RC4] Schneier, B., "Applied Cryptography: Protocols, | [Cross-Protocol] | |||
Algorithms, and Source Code in C, 2nd Ed.", 1996. | Mavrogiannopoulos, N., Vercauteren, F., Velichkov, V., and | |||
B. Preneel, "A cross-protocol attack on the TLS protocol", | ||||
Proceedings of the 2012 ACM Conference in Computer and | ||||
Communications Security, pages 62-72, 2012, | ||||
<http://doi.acm.org/10.1145/2382196.2382206>. | ||||
[RC4-Attack-FMS] | [Delignat14] | |||
Fluhrer, S., Mantin, I., and A. Shamir, "Weaknesses in the | Delignat-Lavaud, A. and K. Bhargavan, "Virtual Host | |||
Key Scheduling Algorithm of RC4", Selected Areas in | Confusion: Weaknesses and Exploits", Black Hat 2014, 2014, | |||
Cryptography , 2001. | <https://bh.ht.vc/vhost_confusion.pdf>. | |||
[RC4-Attack-AlF] | [FFDHE-TLS] | |||
AlFardan, N., Bernstein, D., Paterson, K., Poettering, B., | Gillmor, D., "Negotiated Finite Field Diffie-Hellman | |||
and J. Schuldt, "On the Security of RC4 in TLS", Usenix | Ephemeral Parameters for TLS", Work in Progress, | |||
Security Symposium 2013, 2013, | draft-ietf-tls-negotiated-ff-dhe-05, December 2014. | |||
<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", Proceedings of the 2012 ACM conference on | |||
Computer and Communications Security, pages 38-49, 2012, | ||||
<http://doi.acm.org/10.1145/2382196.2382204>. | <http://doi.acm.org/10.1145/2382196.2382204>. | |||
[Attacks-iSec] | [KEY-PINNING] | |||
Sarkar, P. and S. Fitzgerald, "Attacks on SSL, a | Evans, C., Palmer, C., and R. Sleevi, "Public Key Pinning | |||
comprehensive study of BEAST, CRIME, TIME, BREACH, Lucky13 | Extension for HTTP", Work in Progress, | |||
and RC4 biases", 8 2013, | draft-ietf-websec-key-pinning-21, October 2014. | |||
<https://www.isecpartners.com/media/106031/ | ||||
ssl_attacks_survey.pdf>. | [Klima03] Klima, V., Pokorny, O., and T. Rosa, "Attacking RSA-based | |||
Sessions in SSL/TLS", 2003, | ||||
<https://eprint.iacr.org/2003/052.pdf>. | ||||
[POODLE] Moeller, B., Duong, T., and K. Kotowicz, "This POODLE | ||||
Bites: Exploiting the SSL 3.0 Fallback", September 2014, | ||||
<https://www.openssl.org/~bodo/ssl-poodle.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] | [RC4] Schneier, B., "Applied Cryptography: Protocols, | |||
Mavrogiannopoulos, N., Vercauteren, F., Velichkov, V., and | Algorithms, and Source Code in C", Second Edition, October | |||
B. Preneel, "A cross-protocol attack on the TLS protocol", | 1996. | |||
2012, <http://doi.acm.org/10.1145/2382196.2382206>. | ||||
[RC4-Attack-Pau] | ||||
Paul, G. and S. Maitra, "Permutation after RC4 key | ||||
scheduling reveals the secret key.", 2007, | ||||
<http://dblp.uni-trier.de/db/conf/sacrypt/ | ||||
sacrypt2007.html#PaulM07>. | ||||
[RC4-Attack-Man] | ||||
Mantin, I. and A. Shamir, "A practical attack on broadcast | ||||
RC4", 2001. | ||||
[SSL-Stripping] | ||||
Marlinspike, M., "SSL Stripping", February 2009, | ||||
<http://www.thoughtcrime.org/software/sslstrip/>. | ||||
[Bleichenbacher98] | ||||
Bleichenbacher, D., "Chosen ciphertext attacks against | ||||
protocols based on the RSA encryption standard pkcs1", | ||||
1998. | ||||
[Klima03] Klima, V., Pokorny, O., and T. Rosa, "Attacking RSA-based | ||||
sessions in SSL/TLS", 2003. | ||||
[Brumley03] | ||||
Brumley, D. and D. Boneh, "Remote timing attacks are | ||||
practical", 2003. | ||||
[Brubaker2014using] | [RC4-Attack-AlF] | |||
Brubaker, C., Jana, S., Ray, B., Khurshid, S., and V. | AlFardan, N., Bernstein, D., Paterson, K., Poettering, B., | |||
Shmatikov, "Using frankencerts for automated adversarial | and J. Schuldt, "On the Security of RC4 in TLS", Usenix | |||
testing of certificate validation in SSL/TLS | Security Symposium 2013, August 2013, | |||
implementations", 2014. | <https://www.usenix.org/conference/usenixsecurity13/ | |||
security-rc4-tls>. | ||||
[Delignat14] | [RC4-Attack-FMS] | |||
Delignat-Lavaud, A. and K. Bhargavan, "Virtual Host | Fluhrer, S., Mantin, I., and A. Shamir, "Weaknesses in the | |||
Confusion: Weaknesses and Exploits", Black Hat 2014, 2014. | Key Scheduling Algorithm of RC4", Selected Areas in | |||
Cryptography, August 2001, | ||||
<http://www.crypto.com/papers/others/rc4_ksaproc.pdf>. | ||||
[BhargavanDFPS14] | [RC4-Attack-Man] | |||
Bhargavan, K., Delignat-Lavaud, A., Fournet, C., Pironti, | Mantin, I. and A. Shamir, "A Practical Attack on Broadcast | |||
A., and P. Strub, "Triple handshakes and cookie cutters: | RC4", April 2001, | |||
breaking and fixing authentication over tls", 2014, | <http://saluc.engr.uconn.edu/refs/stream_cipher/ | |||
<http://prosecco.gforge.inria.fr/pubs/ | mantin01attackRC4.pdf>. | |||
triple-handshakes-and-cookie-cutters-sp14.pdf>. | ||||
Appendix A. Appendix: Change Log | [RC4-Attack-Pau] | |||
Paul, G. and S. Maitra, "Permutation After RC4 Key | ||||
Scheduling Reveals the Secret Key", August 2007, | ||||
<http://dblp.uni-trier.de/db/conf/sacrypt/ | ||||
sacrypt2007.html#PaulM07>. | ||||
Note to RFC Editor: please remove this section before publication. | [RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer | |||
Security", RFC 4347, April 2006, | ||||
<http://www.rfc-editor.org/info/rfc4347>. | ||||
A.1. draft-ietf-uta-tls-attacks-05 | [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security | |||
(TLS) Protocol Version 1.2", RFC 5246, August 2008, | ||||
<http://www.rfc-editor.org/info/rfc5246>. | ||||
o Implemented Gen-ART and IESG reviews. | [RFC5288] Salowey, J., Choudhury, A., and D. McGrew, "AES Galois | |||
Counter Mode (GCM) Cipher Suites for TLS", RFC 5288, | ||||
August 2008, <http://www.rfc-editor.org/info/rfc5288>. | ||||
A.2. draft-ietf-uta-tls-attacks-04 | [RFC5705] Rescorla, E., "Keying Material Exporters for Transport | |||
Layer Security (TLS)", RFC 5705, March 2010, | ||||
<http://www.rfc-editor.org/info/rfc5705>. | ||||
o Implemented AD review comments. | [RFC5746] Rescorla, E., Ray, M., Dispensa, S., and N. Oskov, | |||
"Transport Layer Security (TLS) Renegotiation Indication | ||||
Extension", RFC 5746, February 2010, | ||||
<http://www.rfc-editor.org/info/rfc5746>. | ||||
A.3. draft-ietf-uta-tls-attacks-03 | [RFC5929] Altman, J., Williams, N., and L. Zhu, "Channel Bindings | |||
for TLS", RFC 5929, July 2010, | ||||
<http://www.rfc-editor.org/info/rfc5929>. | ||||
o Implemented WG Last Call comments. | [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer | |||
Security Version 1.2", RFC 6347, January 2012, | ||||
<http://www.rfc-editor.org/info/rfc6347>. | ||||
o Virtual host confusion. | [RFC6797] Hodges, J., Jackson, C., and A. Barth, "HTTP Strict | |||
Transport Security (HSTS)", RFC 6797, November 2012, | ||||
<http://www.rfc-editor.org/info/rfc6797>. | ||||
o STARTTLS command injection. | [RFC6989] Sheffer, Y. and S. Fluhrer, "Additional Diffie-Hellman | |||
Tests for the Internet Key Exchange Protocol Version 2 | ||||
(IKEv2)", RFC 6989, July 2013, | ||||
<http://www.rfc-editor.org/info/rfc6989>. | ||||
o Added CVE numbers. | [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an | |||
Attack", BCP 188, RFC 7258, May 2014, | ||||
<http://www.rfc-editor.org/info/rfc7258>. | ||||
A.4. draft-ietf-uta-tls-attacks-02 | [RFC7366] Gutmann, P., "Encrypt-then-MAC for Transport Layer | |||
Security (TLS) and Datagram Transport Layer Security | ||||
(DTLS)", RFC 7366, September 2014, | ||||
<http://www.rfc-editor.org/info/rfc7366>. | ||||
o Added implementation issues ("most dangerous code"), | [SECURE-TLS] | |||
renegotiation, triple handshake. | Sheffer, Y., Holz, R., and P. Saint-Andre, | |||
"Recommendations for Secure Use of TLS and DTLS", Work in | ||||
Progress, draft-ietf-uta-tls-bcp-08, December 2014. | ||||
o Added text re: mitigation of Lucky13. | [SSL-Stripping] | |||
Marlinspike, M., "sslstrip", February 2009, | ||||
<http://www.thoughtcrime.org/software/sslstrip/>. | ||||
o Added applicability to DTLS. | [TIME] Be'ery, T. and A. Shulman, "A Perfect CRIME? Only TIME | |||
Will Tell", Black Hat Europe 2013, 2013, | ||||
<https://media.blackhat.com/eu-13/briefings/Beery/ | ||||
bh-eu-13-a-perfect-crime-beery-wp.pdf>. | ||||
A.5. draft-ietf-uta-tls-attacks-01 | Acknowledgements | |||
o Added SSL Stripping, attacks related to certificates, Diffie | We would like to thank Stephen Farrell, Simon Josefsson, John | |||
Hellman parameters and denial of service. | Mattsson, Yoav Nir, Kenny Paterson, Patrick Pelletier, Tom Ritter, | |||
Rich Salz, and Meral Shirazipour for their feedback on 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, and Chris Newman for | ||||
text on STARTTLS command injection. Ralph Holz gratefully | ||||
acknowledges the support of NICTA (National ICT of Australia) in the | ||||
preparation of this document. | ||||
o Expanded on RC4 attacks, thanks to Andrei Popov. | During IESG review, Richard Barnes, Barry Leiba, and Kathleen | |||
Moriarty caught several issues that needed to be addressed. | ||||
A.6. draft-ietf-uta-tls-attacks-00 | 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. | ||||
o Initial version, extracted from draft-sheffer-tls-bcp-01. | The document was prepared using the lyx2rfc tool, created by Nico | |||
Williams. | ||||
Authors' Addresses | Authors' Addresses | |||
Yaron Sheffer | Yaron Sheffer | |||
Porticor | Porticor | |||
29 HaHarash St. | 29 HaHarash St. | |||
Hod HaSharon 4501303 | Hod HaSharon 4501303 | |||
Israel | Israel | |||
Email: yaronf.ietf@gmail.com | EMail: yaronf.ietf@gmail.com | |||
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 | |||
Email: peter@andyet.com | EMail: peter@andyet.com | |||
URI: https://andyet.com/ | URI: https://andyet.com/ | |||
End of changes. 85 change blocks. | ||||
310 lines changed or deleted | 276 lines changed or added | |||
This html diff was produced by rfcdiff 1.42. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |