idnits 2.17.1
draft-ietf-uta-tls-attacks-04.txt:
Checking boilerplate required by RFC 5378 and the IETF Trust (see
https://trustee.ietf.org/license-info):
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/checklist :
----------------------------------------------------------------------------
No issues found here.
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the IETF Trust and authors Copyright Line does not
match the current year
-- The document date (September 28, 2014) is 3492 days in the past. Is
this intentional?
Checking references for intended status: Informational
----------------------------------------------------------------------------
-- Obsolete informational reference (is this intentional?): RFC 4347
(Obsoleted by RFC 6347)
-- Obsolete informational reference (is this intentional?): RFC 5246
(Obsoleted by RFC 8446)
-- Obsolete informational reference (is this intentional?): RFC 6347
(Obsoleted by RFC 9147)
== Outdated reference: A later version (-11) exists of
draft-ietf-uta-tls-bcp-01
== Outdated reference: A later version (-01) exists of
draft-ietf-tls-prohibiting-rc4-00
Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 4 comments (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 uta Y. Sheffer
3 Internet-Draft Porticor
4 Intended status: Informational R. Holz
5 Expires: April 1, 2015 TUM
6 P. Saint-Andre
7 &yet
8 September 28, 2014
10 Summarizing Current Attacks on TLS and DTLS
11 draft-ietf-uta-tls-attacks-04
13 Abstract
15 Over the last few years there have been several serious attacks on
16 TLS, including attacks on its most commonly used ciphers and modes of
17 operation. This document summarizes these attacks, with the goal of
18 motivating generic and protocol-specific recommendations on the usage
19 of TLS and DTLS.
21 Status of This Memo
23 This Internet-Draft is submitted in full conformance with the
24 provisions of BCP 78 and BCP 79.
26 Internet-Drafts are working documents of the Internet Engineering
27 Task Force (IETF). Note that other groups may also distribute
28 working documents as Internet-Drafts. The list of current Internet-
29 Drafts is at http://datatracker.ietf.org/drafts/current/.
31 Internet-Drafts are draft documents valid for a maximum of six months
32 and may be updated, replaced, or obsoleted by other documents at any
33 time. It is inappropriate to use Internet-Drafts as reference
34 material or to cite them other than as "work in progress."
36 This Internet-Draft will expire on April 1, 2015.
38 Copyright Notice
40 Copyright (c) 2014 IETF Trust and the persons identified as the
41 document authors. All rights reserved.
43 This document is subject to BCP 78 and the IETF Trust's Legal
44 Provisions Relating to IETF Documents
45 (http://trustee.ietf.org/license-info) in effect on the date of
46 publication of this document. Please review these documents
47 carefully, as they describe your rights and restrictions with respect
48 to this document. Code Components extracted from this document must
49 include Simplified BSD License text as described in Section 4.e of
50 the Trust Legal Provisions and are provided without warranty as
51 described in the Simplified BSD License.
53 Table of Contents
55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
56 2. Attacks on TLS . . . . . . . . . . . . . . . . . . . . . . . 3
57 2.1. SSL Stripping . . . . . . . . . . . . . . . . . . . . . . . 3
58 2.2. STARTTLS Command Injection Attack (CVE-2011-0411) . . . . . 3
59 2.3. BEAST (CVE-2011-3389) . . . . . . . . . . . . . . . . . . . 4
60 2.4. Lucky Thirteen (CVE-2013-0169) . . . . . . . . . . . . . . 4
61 2.5. Attacks on RC4 . . . . . . . . . . . . . . . . . . . . . . 4
62 2.6. Compression Attacks: CRIME, TIME and BREACH . . . . . . . . 4
63 2.7. Certificate Attacks . . . . . . . . . . . . . . . . . . . . 5
64 2.8. Diffie-Hellman Parameters . . . . . . . . . . . . . . . . . 5
65 2.9. Renegotiation (CVE-2009-3555) . . . . . . . . . . . . . . . 5
66 2.10. Triple Handshake (CVE-2014-1295) . . . . . . . . . . . . . 5
67 2.11. Virtual Host Confusion . . . . . . . . . . . . . . . . . . 6
68 2.12. Denial of Service . . . . . . . . . . . . . . . . . . . . . 6
69 2.13. Implementation Issues . . . . . . . . . . . . . . . . . . . 6
70 3. Applicability to DTLS . . . . . . . . . . . . . . . . . . . . 7
71 4. Security Considerations . . . . . . . . . . . . . . . . . . . 7
72 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
73 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7
74 7. Informative References . . . . . . . . . . . . . . . . . . . 7
75 Appendix A. Appendix: Change Log . . . . . . . . . . . . . . . . 10
76 A.1. draft-ietf-uta-tls-attacks-04 . . . . . . . . . . . . . . . 10
77 A.2. draft-ietf-uta-tls-attacks-03 . . . . . . . . . . . . . . . 10
78 A.3. draft-ietf-uta-tls-attacks-02 . . . . . . . . . . . . . . . 11
79 A.4. draft-ietf-uta-tls-attacks-01 . . . . . . . . . . . . . . . 11
80 A.5. draft-ietf-uta-tls-attacks-00 . . . . . . . . . . . . . . . 11
81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
83 1. Introduction
85 Over the last few years there have been several major attacks on TLS
86 [RFC5246], including attacks on its most commonly used ciphers and
87 modes of operation. Details are given in Section 2, but suffice it
88 to say that both AES-CBC and RC4, which together make up for most
89 current usage, have been seriously attacked in the context of TLS.
91 This situation was one of the motivations for the creation of the UTA
92 working group, which is tasked with the creation of generic and
93 protocol-specific recommendations for the use of TLS and DTLS.
95 "Attacks always get better; they never get worse" (ironically, this
96 saying is attributed to the NSA). This list of attacks describes our
97 knowledge as of this writing. It seems likely that new attacks will
98 be invented in the future.
100 For a more detailed discussion of the attacks listed here, the
101 interested reader is referred to [Attacks-iSec].
103 2. Attacks on TLS
105 This section lists the attacks that motivated the current
106 recommendations. This is not intended to be an extensive survey of
107 TLS's security.
109 While there are widely deployed mitigations for some of the attacks
110 listed below, we believe that their root causes necessitate a more
111 systemic solution.
113 When such an identifier exists for an attack, we have included its
114 CVE (Common Vulnerabilities and Exposures) ID. CVE [CVE] is an
115 extensive, industry-wide database of software vulnerabilities.
117 2.1. SSL Stripping
119 Various attacks attempt to remove the use of SSL/TLS altogether, by
120 modifying unencrypted protocols that request the use of TLS,
121 specifically modifying HTTP traffic and HTML pages as they pass on
122 the wire. These attacks are known collectively as SSL Stripping and
123 were first introduced by Moxie Marlinspike [SSL-Stripping]. In the
124 context of Web traffic, these attacks are only effective if the
125 client initially accesses a Web server using HTTP. A commonly used
126 mitigation is HTTP Strict Transport Security (HSTS) [RFC6797].
128 2.2. STARTTLS Command Injection Attack (CVE-2011-0411)
130 Similarly, there are attacks on the transition between unprotected
131 and TLS-protected traffic. A number of IETF application protocols
132 have used an application-level command, usually STARTTLS, to upgrade
133 a clear-text connection to use TLS. Multiple implementations of
134 STARTTLS had a flaw where an application-layer input buffer retained
135 commands that were pipelined with the STARTTLS command, such that
136 commands received prior to TLS negotiation are executed after TLS
137 negotiation. This problem is resolved by requiring the application-
138 level command input buffer to be empty before negotiating TLS. Note
139 that this flaw lives in the application layer code and does not
140 impact the TLS protocol directly.
142 2.3. BEAST (CVE-2011-3389)
144 The BEAST attack [BEAST] uses issues with the TLS 1.0 implementation
145 of CBC (that is, the predictable initialization vector) to decrypt
146 parts of a packet, and specifically to decrypt HTTP cookies when HTTP
147 is run over TLS.
149 2.4. Lucky Thirteen (CVE-2013-0169)
151 A consequence of the MAC-then-encrypt design in all current versions
152 of TLS is the existence of padding oracle attacks [Padding-Oracle].
153 A recent incarnation of these attacks is the Lucky Thirteen attack
154 [CBC-Attack], a timing side-channel attack that allows the attacker
155 to decrypt arbitrary ciphertext.
157 The Lucky Thirteen attack can be mitigated by using authenticated
158 encryption like AES-GCM [RFC5288] or encrypt-then-mac
159 [I-D.ietf-tls-encrypt-then-mac] instead of the TLS default of MAC-
160 then-encrypt.
162 2.5. Attacks on RC4
164 The RC4 algorithm [RC4] has been used with TLS (and previously, SSL)
165 for many years. RC4 has long been known to have a variety of
166 cryptographic weaknesses, e.g. [RC4-Attack-Pau], [RC4-Attack-Man],
167 [RC4-Attack-FMS]. Recent cryptanalysis results [RC4-Attack-AlF]
168 exploit biases in the RC4 keystream to recover repeatedly encrypted
169 plaintexts.
171 These recent results are on the verge of becoming practically
172 exploitable; currently they require 2^26 sessions or 13x2^30
173 encryptions. As a result, RC4 can no longer be seen as providing a
174 sufficient level of security for TLS sessions. For further details,
175 the reader is referred to [I-D.ietf-tls-prohibiting-rc4].
177 2.6. Compression Attacks: CRIME, TIME and BREACH
179 The CRIME attack [CRIME] (CVE-2012-4929) allows an active attacker to
180 decrypt ciphertext (specifically, cookies) when TLS is used with TLS
181 level compression.
183 The TIME attack [TIME] and the later BREACH attack [BREACH]
184 (CVE-2013-3587, though the number has not been officially allocated)
185 both make similar use of HTTP-level compression to decrypt secret
186 data passed in the HTTP response. We note that compression of the
187 HTTP message body is much more prevalent than compression at the TLS
188 level.
190 The former attack can be mitigated by disabling TLS compression. We
191 are not aware of mitigations at the TLS protocol level to the latter
192 attack, and so application-level mitigations are needed (see
193 [BREACH]). For example, implementations of HTTP that use CSRF tokens
194 will need to randomize them even when the recommendations of
195 [I-D.ietf-uta-tls-bcp] are adopted.
197 2.7. Certificate Attacks
199 There have been several practical attacks on TLS when used with RSA
200 certificates (the most common use case). These include
201 [Bleichenbacher98] and [Klima03]. While the Bleichenbacher attack
202 has been mitigated in TLS 1.0, the Klima attack that relies on a
203 version-check oracle is only mitigated by TLS 1.1.
205 The use of RSA certificates often involves exploitable timing issues
206 [Brumley03] (CVE-2003-0147), unless the implementation takes care to
207 explicitly eliminate them.
209 A recent certificate fuzzing tool [Brubaker2014using] uncovered
210 numerous vulnerabilities in different TLS libraries, related to
211 certificate validation.
213 2.8. Diffie-Hellman Parameters
215 TLS allows the definition of ephemeral Diffie-Hellman and Elliptic
216 Curve Diffie-Hellman parameters in its respective key exchange modes.
217 This results in an attack detailed in [Cross-Protocol]. In addition,
218 clients that do not properly verify the received parameters are
219 exposed to man in the middle (MITM) attacks. Unfortunately the TLS
220 protocol does not require this verification, see [RFC6989] for the
221 IPsec analogy.
223 2.9. Renegotiation (CVE-2009-3555)
225 A major attack on the TLS renegotiation mechanism applies to all
226 current versions of the protocol. The attack and the TLS extension
227 that resolves it are described in [RFC5746].
229 2.10. Triple Handshake (CVE-2014-1295)
231 The triple handshake attack [[TRIPLE-HS, add the reference when
232 published]] enables the attacker to cause two TLS connections to
233 share keying material. This leads to a multitude of attacks, e.g.
234 Man-in-the-Middle, breaking safe renegotiation and breaking channel
235 binding via TLS Exporter [RFC5705] or "tls-unique" [RFC5929].
237 2.11. Virtual Host Confusion
239 A recent article [Delignat14] describes a security issue whereby
240 SSLv3 fallback and improper handling of session caches on the server
241 side can be abused by an attacker to establish a malicious connection
242 to a virtual host other than originally intended and approved by the
243 server. This attack is especially serious in performance critical
244 environments where sharing of SSLv3 session caches is very common.
246 2.12. Denial of Service
248 Server CPU power has progressed over the years so that TLS can now be
249 turned on by default. However the risk of malicious clients and
250 coordinated groups of clients ("botnets") mounting denial of service
251 attacks is still very real. TLS adds another vector for
252 computational attacks, since a client can easily (with little
253 computational effort) force the server to expend relatively large
254 computational work. It is known that such attacks have in fact been
255 mounted.
257 2.13. Implementation Issues
259 Even when the protocol is fully specified, there are very common
260 issues that often plague implementations. In particular, when
261 integrating into higher-level protocols, TLS and its PKI-based
262 authentication are sometimes the source of misunderstandings and
263 implementation "shortcuts". An extensive survey of these issues can
264 be found in [Georgiev2012].
266 o Implementations may omit validation of the server certificate
267 altogether. For example, this is true of the default
268 implementation of HTTP client libraries in Python 2 (see e.g.
269 CVE-2013-2191).
271 o Implementations may not validate the server identity. This
272 validation typically amounts to matching the protocol-level server
273 name with the certificate's Subject Alternative Name field. Note:
274 historically, although incorrect, this information is also often
275 found in the Common Name part of the Distinguished Name instead.
277 o Implementations may be validating the certificate chain
278 incorrectly or not at all, or using an incorrect or outdated trust
279 anchor list.
281 3. Applicability to DTLS
283 DTLS [RFC4347] [RFC6347] is an adaptation of TLS for UDP datagrams.
285 With respect to the attacks described in the current document, DTLS
286 1.0 is equivalent to TLS 1.1. The only exception is RC4 which is
287 disallowed in DTLS. DTLS 1.2 is equivalent to TLS 1.2.
289 4. Security Considerations
291 This document describes protocol attacks in an informational manner,
292 and in itself does not have any security implications. Its companion
293 documents certainly do.
295 5. IANA Considerations
297 This document requires no IANA actions. [Note to RFC Editor: please
298 remove this whole section before publication.]
300 6. Acknowledgments
302 We would like to thank Stephen Farrell, Simon Josefsson, John
303 Mattsson, Yoav Nir, Kenny Paterson, Patrick Pelletier, Tom Ritter and
304 Rich Salz for their review of this document. We thank Andrei Popov
305 for contributing text on RC4, Kohei Kasamatsu for text on Lucky13,
306 Ilari Liusvaara for text on attacks and on DTLS, Aaron Zauner for
307 text on virtual host confusion, Chris Newman for text on STARTTLS
308 command injection.
310 The document was prepared using the lyx2rfc tool, created by Nico
311 Williams.
313 7. Informative References
315 [RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
316 Security", RFC 4347, April 2006.
318 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
319 (TLS) Protocol Version 1.2", RFC 5246, August 2008.
321 [RFC5288] Salowey, J., Choudhury, A., and D. McGrew, "AES Galois
322 Counter Mode (GCM) Cipher Suites for TLS", RFC 5288,
323 August 2008.
325 [RFC5705] Rescorla, E., "Keying Material Exporters for Transport
326 Layer Security (TLS)", RFC 5705, March 2010.
328 [RFC5746] Rescorla, E., Ray, M., Dispensa, S., and N. Oskov,
329 "Transport Layer Security (TLS) Renegotiation Indication
330 Extension", RFC 5746, February 2010.
332 [RFC5929] Altman, J., Williams, N., and L. Zhu, "Channel Bindings
333 for TLS", RFC 5929, July 2010.
335 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
336 Security Version 1.2", RFC 6347, January 2012.
338 [RFC6797] Hodges, J., Jackson, C., and A. Barth, "HTTP Strict
339 Transport Security (HSTS)", RFC 6797, November 2012.
341 [RFC6989] Sheffer, Y. and S. Fluhrer, "Additional Diffie-Hellman
342 Tests for the Internet Key Exchange Protocol Version 2
343 (IKEv2)", RFC 6989, July 2013.
345 [I-D.ietf-uta-tls-bcp]
346 Sheffer, Y., Holz, R., and P. Saint-Andre,
347 "Recommendations for Secure Use of TLS and DTLS", draft-
348 ietf-uta-tls-bcp-01 (work in progress), June 2014.
350 [I-D.ietf-tls-prohibiting-rc4]
351 Popov, A., "Prohibiting RC4 Cipher Suites", draft-ietf-
352 tls-prohibiting-rc4-00 (work in progress), July 2014.
354 [I-D.ietf-tls-encrypt-then-mac]
355 Gutmann, P., "Encrypt-then-MAC for TLS and DTLS", draft-
356 ietf-tls-encrypt-then-mac-03 (work in progress), July
357 2014.
359 [CVE] MITRE, , "Common Vulnerabilities and Exposures",
360 .
362 [CBC-Attack]
363 AlFardan, N. and K. Paterson, "Lucky Thirteen: Breaking
364 the TLS and DTLS Record Protocols", IEEE Symposium on
365 Security and Privacy , 2013.
367 [BEAST] Rizzo, J. and T. Duong, "Browser Exploit Against SSL/TLS",
368 2011, .
371 [CRIME] Rizzo, J. and T. Duong, "The CRIME Attack", EKOparty
372 Security Conference 2012, 2012.
374 [BREACH] Prado, A., Harris, N., and Y. Gluck, "The BREACH Attack",
375 2013, .
377 [TIME] Be'ery, T. and A. Shulman, "A Perfect CRIME? Only TIME
378 Will Tell", Black Hat Europe 2013, 2013,
379 .
382 [RC4] Schneier, B., "Applied Cryptography: Protocols,
383 Algorithms, and Source Code in C, 2nd Ed.", 1996.
385 [RC4-Attack-FMS]
386 Fluhrer, S., Mantin, I., and A. Shamir, "Weaknesses in the
387 Key Scheduling Algorithm of RC4", Selected Areas in
388 Cryptography , 2001.
390 [RC4-Attack-AlF]
391 AlFardan, N., Bernstein, D., Paterson, K., Poettering, B.,
392 and J. Schuldt, "On the Security of RC4 in TLS", Usenix
393 Security Symposium 2013, 2013, .
396 [Georgiev2012]
397 Georgiev, M., Iyengar, S., Jana, S., Anubhai, R., Boneh,
398 D., and V. Shmatikov, "The most dangerous code in the
399 world: validating SSL certificates in non-browser
400 software", 2012,
401 .
403 [Attacks-iSec]
404 Sarkar, P. and S. Fitzgerald, "Attacks on SSL, a
405 comprehensive study of BEAST, CRIME, TIME, BREACH, Lucky13
406 and RC4 biases", 8 2013, .
409 [Padding-Oracle]
410 Vaudenay, S., "Security Flaws Induced by CBC Padding
411 Applications to SSL, IPSEC, WTLS...", EUROCRYPT 2002,
412 2002, .
415 [Cross-Protocol]
416 Mavrogiannopoulos, N., Vercauteren, F., Velichkov, V., and
417 B. Preneel, "A cross-protocol attack on the TLS protocol",
418 2012, .
420 [RC4-Attack-Pau]
421 Paul, G. and S. Maitra, "Permutation after RC4 key
422 scheduling reveals the secret key.", 2007,
423 .
426 [RC4-Attack-Man]
427 Mantin, I. and A. Shamir, "A practical attack on broadcast
428 RC4", 2001.
430 [SSL-Stripping]
431 Marlinspike, M., "SSL Stripping", February 2009,
432 .
434 [Bleichenbacher98]
435 Bleichenbacher, D., "Chosen ciphertext attacks against
436 protocols based on the RSA encryption standard pkcs1",
437 1998.
439 [Klima03] Klima, V., Pokorny, O., and T. Rosa, "Attacking RSA-based
440 sessions in SSL/TLS", 2003.
442 [Brumley03]
443 Brumley, D. and D. Boneh, "Remote timing attacks are
444 practical", 2003.
446 [Brubaker2014using]
447 Brubaker, C., Jana, S., Ray, B., Khurshid, S., and V.
448 Shmatikov, "Using frankencerts for automated adversarial
449 testing of certificate validation in SSL/TLS
450 implementations", 2014.
452 [Delignat14]
453 Delignat-Lavaud, A. and K. Bhargavan, "Virtual Host
454 Confusion: Weaknesses and Exploits", Black Hat 2014, 2014.
456 Appendix A. Appendix: Change Log
458 Note to RFC Editor: please remove this section before publication.
460 A.1. draft-ietf-uta-tls-attacks-04
462 o Implemented AD review comments.
464 A.2. draft-ietf-uta-tls-attacks-03
466 o Implemented WG Last Call comments.
468 o Virtual host confusion.
470 o STARTTLS command injection.
472 o Added CVE numbers.
474 A.3. draft-ietf-uta-tls-attacks-02
476 o Added implementation issues ("most dangerous code"),
477 renegotiation, triple handshake.
479 o Added text re: mitigation of Lucky13.
481 o Added applicability to DTLS.
483 A.4. draft-ietf-uta-tls-attacks-01
485 o Added SSL Stripping, attacks related to certificates, Diffie
486 Hellman parameters and denial of service.
488 o Expanded on RC4 attacks, thanks to Andrei Popov.
490 A.5. draft-ietf-uta-tls-attacks-00
492 o Initial version, extracted from draft-sheffer-tls-bcp-01.
494 Authors' Addresses
496 Yaron Sheffer
497 Porticor
498 29 HaHarash St.
499 Hod HaSharon 4501303
500 Israel
502 Email: yaronf.ietf@gmail.com
504 Ralph Holz
505 Technische Universitaet Muenchen
506 Boltzmannstr. 3
507 Garching 85748
508 Germany
510 Email: holz@net.in.tum.de
512 Peter Saint-Andre
513 &yet
514 P.O. Box 787
515 Parker, CO 80134
516 USA
518 Email: peter@andyet.com