idnits 2.17.1 draft-ietf-uta-tls-attacks-03.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 9, 2014) is 3517 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: March 13, 2015 TUM 6 P. Saint-Andre 7 &yet 8 September 9, 2014 10 Summarizing Current Attacks on TLS and DTLS 11 draft-ietf-uta-tls-attacks-03 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 March 13, 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) . . . . . . . . . . . . . . . . . . . 3 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 . . . . . . . . . . . . . . . . . . 5 68 2.12. Denial of Service . . . . . . . . . . . . . . . . . . . . . 6 69 2.13. Implementation Issues . . . . . . . . . . . . . . . . . . . 6 70 3. Applicability to DTLS . . . . . . . . . . . . . . . . . . . . 6 71 4. Security Considerations . . . . . . . . . . . . . . . . . . . 6 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-03 . . . . . . . . . . . . . . . 10 77 A.2. draft-ietf-uta-tls-attacks-02 . . . . . . . . . . . . . . . 10 78 A.3. draft-ietf-uta-tls-attacks-01 . . . . . . . . . . . . . . . 10 79 A.4. draft-ietf-uta-tls-attacks-00 . . . . . . . . . . . . . . . 11 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 82 1. Introduction 84 Over the last few years there have been several major attacks on TLS 85 [RFC5246], including attacks on its most commonly used ciphers and 86 modes of operation. Details are given in Section 2, but suffice it 87 to say that both AES-CBC and RC4, which together make up for most 88 current usage, have been seriously attacked in the context of TLS. 90 This situation motivated the creation of the UTA working group, which 91 is tasked with the creation of generic and protocol-specific 92 recommendations for the use of TLS and DTLS. 94 "Attacks always get better; they never get worse" (ironically, this 95 saying is attributed to the NSA). This list of attacks describes our 96 knowledge as of this writing. It seems likely that new attacks will 97 be invented in the future. 99 For a more detailed discussion of the attacks listed here, the 100 interested reader is referred to [Attacks-iSec]. 102 2. Attacks on TLS 104 This section lists the attacks that motivated the current 105 recommendations. This is not intended to be an extensive survey of 106 TLS's security. 108 While there are widely deployed mitigations for some of the attacks 109 listed below, we believe that their root causes necessitate a more 110 systemic solution. 112 2.1. SSL Stripping 114 Various attacks attempt to remove the use of SSL/TLS altogether, by 115 modifying unencrypted protocols that request the use of TLS, 116 specifically modifying HTTP traffic and HTML pages as they pass on 117 the wire. These attacks are known collectively as SSL Stripping and 118 were first introduced by Moxie Marlinspike [SSL-Stripping]. In the 119 context of Web traffic, these attacks are only effective if the 120 client initially accesses a Web server using HTTP. A commonly used 121 mitigation is HTTP Strict Transport Security (HSTS) [RFC6797]. 123 2.2. STARTTLS Command Injection Attack (CVE-2011-0411) 125 Similarly, there are attacks on the transition between unprotected 126 and TLS-protected traffic. A number of IETF application protocols 127 have used an application-level command, usually STARTTLS, to upgrade 128 a clear-text connection to use TLS. Multiple implementations of 129 STARTTLS had a flaw where an application-layer input buffer retained 130 commands that were pipelined with the STARTTLS command, such that 131 commands received prior to TLS negotiation are executed after TLS 132 negotiation. This problem is resolved by requiring the application- 133 level command input buffer to be empty before negotiating TLS. Note 134 that this flaw lives in the application layer code and does not 135 impact the TLS protocol directly. 137 2.3. BEAST (CVE-2011-3389) 139 The BEAST attack [BEAST] uses issues with the TLS 1.0 implementation 140 of CBC (that is, the predictable initialization vector) to decrypt 141 parts of a packet, and specifically to decrypt HTTP cookies when HTTP 142 is run over TLS. 144 2.4. Lucky Thirteen (CVE-2013-0169) 146 A consequence of the MAC-then-encrypt design in all current versions 147 of TLS is the existence of padding oracle attacks [Padding-Oracle]. 148 A recent incarnation of these attacks is the Lucky Thirteen attack 149 [CBC-Attack], a timing side-channel attack that allows the attacker 150 to decrypt arbitrary ciphertext. 152 The Lucky Thirteen attack can be mitigated by using authenticated 153 encryption like AES-GCM [RFC5288] or encrypt-then-mac 154 [I-D.ietf-tls-encrypt-then-mac] instead of the TLS default of MAC- 155 then-encrypt. 157 2.5. Attacks on RC4 159 The RC4 algorithm [RC4] has been used with TLS (and previously, SSL) 160 for many years. RC4 has long been known to have a variety of 161 cryptographic weaknesses, e.g. [RC4-Attack-Pau], [RC4-Attack-Man], 162 [RC4-Attack-FMS]. Recent cryptanalysis results [RC4-Attack-AlF] 163 exploit biases in the RC4 keystream to recover repeatedly encrypted 164 plaintexts. 166 These recent results are on the verge of becoming practically 167 exploitable; currently they require 2^26 sessions or 13x2^30 168 encryptions. As a result, RC4 can no longer be seen as providing a 169 sufficient level of security for TLS sessions. For further details, 170 the reader is referred to [I-D.ietf-tls-prohibiting-rc4]. 172 2.6. Compression Attacks: CRIME, TIME and BREACH 174 The CRIME attack [CRIME] (CVE-2012-4929) allows an active attacker to 175 decrypt ciphertext (specifically, cookies) when TLS is used with TLS 176 level compression. 178 The TIME attack [TIME] and the later BREACH attack [BREACH] 179 (CVE-2013-3587, though the number has not been officially allocated) 180 both make similar use of HTTP-level compression to decrypt secret 181 data passed in the HTTP response. We note that compression of the 182 HTTP message body is much more prevalent than compression at the TLS 183 level. 185 The former attack can be mitigated by disabling TLS compression. We 186 are not aware of mitigations at the TLS protocol level to the latter 187 attack, and so application-level mitigations are needed (see 188 [BREACH]). For example, implementations of HTTP that use CSRF tokens 189 will need to randomize them even when the recommendations of 190 [I-D.ietf-uta-tls-bcp] are adopted. 192 2.7. Certificate Attacks 194 There have been several practical attacks on TLS when used with RSA 195 certificates (the most common use case). These include 196 [Bleichenbacher98] and [Klima03]. While the Bleichenbacher attack 197 has been mitigated in TLS 1.0, the Klima attack that relies on a 198 version-check oracle is only mitigated by TLS 1.1. 200 The use of RSA certificates often involves exploitable timing issues 201 [Brumley03] (CVE-2003-0147), unless the implementation takes care to 202 explicitly eliminate them. 204 A recent certificate fuzzing tool [Brubaker2014using] uncovered 205 numerous vulnerabilities in different TLS libraries, related to 206 certificate validation. 208 2.8. Diffie-Hellman Parameters 210 TLS allows to define ephemeral Diffie-Hellman and Elliptic Curve 211 Diffie-Hellman parameters in its respective key exchange modes. This 212 results in an attack detailed in [Cross-Protocol]. In addition, 213 clients that do not properly verify the received parameters are 214 exposed to man in the middle (MITM) attacks. Unfortunately the TLS 215 protocol does not require this verification, see [RFC6989] for the 216 IPsec analogy. 218 2.9. Renegotiation (CVE-2009-3555) 220 A major attack on the TLS renegotiation mechanism applies to all 221 current versions of the protocol. The attack and the TLS extension 222 that resolves it are described in [RFC5746]. 224 2.10. Triple Handshake (CVE-2014-1295) 226 The triple handshake attack [[TRIPLE-HS, add the reference when 227 published]] enables the attacker to cause two TLS connections to 228 share keying material. This leads to a multitude of attacks, e.g. 229 Man-in-the-Middle, breaking safe renegotiation and breaking channel 230 binding via TLS Exporter [RFC5705] or "tls-unique" [RFC5929]. 232 2.11. Virtual Host Confusion 234 A recent article [Delignat14] describes a security issue whereby 235 SSLv3 fallback and improper handling of session caches on the server 236 side can be abused by an attacker to establish a malicious connection 237 to a virtual host other than originally intended and approved by the 238 server. This attack is especially serious in performance critical 239 environments where sharing of SSLv3 session caches is very common. 241 2.12. Denial of Service 243 Server CPU power has progressed over the years so that TLS can now be 244 turned on by default. However the risk of malicious clients and 245 coordinated groups of clients ("botnets") mounting denial of service 246 attacks is still very real. TLS adds another vector for 247 computational attacks, since a client can easily (with little 248 computational effort) force the server to expend relatively large 249 computational work. It is known that such attacks have in fact been 250 mounted. 252 2.13. Implementation Issues 254 Even when the protocol is fully specified, the are very common issues 255 that often plague implementations. In particular, the integration of 256 higher-level protocols, TLS and its PKI-based authentication is the 257 source of misunderstandings and implementation "shortcuts". An 258 extensive survey of these issues can be found in [Georgiev2012]. 260 o Implementations may omit validation of the server certificate 261 altogether. For example, this is true of the default 262 implementation of HTTP client libraries in Python 2 (see e.g. 263 CVE-2013-2191). 265 o Implementations may not validate the server identity. This 266 validation typically amounts to matching the protocol-level server 267 name with the certificate's Subject Alternative Name field. Note: 268 historically, although incorrect, this information is also often 269 found in the Common Name part of the Distinguished Name instead. 271 o Implementations may be validating the certificate chain 272 incorrectly or not at all, or using an incorrect or outdated trust 273 anchor list. 275 3. Applicability to DTLS 277 DTLS [RFC4347] [RFC6347] is an adaptation of TLS for UDP datagrams. 279 With respect to the attacks described in the current document, DTLS 280 1.0 is equivalent to TLS 1.1. The only exception is RC4 which is 281 disallowed in DTLS. DTLS 1.2 is equivalent to TLS 1.2. 283 4. Security Considerations 285 This document describes protocol attacks in an informational manner, 286 and in itself does not have any security implications. Its companion 287 documents certainly do. 289 5. IANA Considerations 291 This document requires no IANA actions. [Note to RFC Editor: please 292 remove this whole section before publication.] 294 6. Acknowledgments 296 We would like to thank Stephen Farrell, Simon Josefsson, John 297 Mattsson, Yoav Nir, Kenny Paterson, Patrick Pelletier, Tom Ritter and 298 Rich Salz for their review of this document. We thank Andrei Popov 299 for contributing text on RC4, Kohei Kasamatsu for text on Lucky13, 300 Ilari Liusvaara for text on attacks and on DTLS, Aaron Zauner for 301 text on virtual host confusion, Chris Newman for text on STARTTLS 302 command injection. 304 The document was prepared using the lyx2rfc tool, created by Nico 305 Williams. 307 7. Informative References 309 [RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 310 Security", RFC 4347, April 2006. 312 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 313 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 315 [RFC5288] Salowey, J., Choudhury, A., and D. McGrew, "AES Galois 316 Counter Mode (GCM) Cipher Suites for TLS", RFC 5288, 317 August 2008. 319 [RFC5705] Rescorla, E., "Keying Material Exporters for Transport 320 Layer Security (TLS)", RFC 5705, March 2010. 322 [RFC5746] Rescorla, E., Ray, M., Dispensa, S., and N. Oskov, 323 "Transport Layer Security (TLS) Renegotiation Indication 324 Extension", RFC 5746, February 2010. 326 [RFC5929] Altman, J., Williams, N., and L. Zhu, "Channel Bindings 327 for TLS", RFC 5929, July 2010. 329 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 330 Security Version 1.2", RFC 6347, January 2012. 332 [RFC6797] Hodges, J., Jackson, C., and A. Barth, "HTTP Strict 333 Transport Security (HSTS)", RFC 6797, November 2012. 335 [RFC6989] Sheffer, Y. and S. Fluhrer, "Additional Diffie-Hellman 336 Tests for the Internet Key Exchange Protocol Version 2 337 (IKEv2)", RFC 6989, July 2013. 339 [I-D.ietf-uta-tls-bcp] 340 Sheffer, Y., Holz, R., and P. Saint-Andre, 341 "Recommendations for Secure Use of TLS and DTLS", draft- 342 ietf-uta-tls-bcp-01 (work in progress), June 2014. 344 [I-D.ietf-tls-prohibiting-rc4] 345 Popov, A., "Prohibiting RC4 Cipher Suites", draft-ietf- 346 tls-prohibiting-rc4-00 (work in progress), July 2014. 348 [I-D.ietf-tls-encrypt-then-mac] 349 Gutmann, P., "Encrypt-then-MAC for TLS and DTLS", draft- 350 ietf-tls-encrypt-then-mac-03 (work in progress), July 351 2014. 353 [CBC-Attack] 354 AlFardan, N. and K. Paterson, "Lucky Thirteen: Breaking 355 the TLS and DTLS Record Protocols", IEEE Symposium on 356 Security and Privacy , 2013. 358 [BEAST] Rizzo, J. and T. Duong, "Browser Exploit Against SSL/TLS", 359 2011, . 362 [CRIME] Rizzo, J. and T. Duong, "The CRIME Attack", EKOparty 363 Security Conference 2012, 2012. 365 [BREACH] Prado, A., Harris, N., and Y. Gluck, "The BREACH Attack", 366 2013, . 368 [TIME] Be'ery, T. and A. Shulman, "A Perfect CRIME? Only TIME 369 Will Tell", Black Hat Europe 2013, 2013, 370 . 373 [RC4] Schneier, B., "Applied Cryptography: Protocols, 374 Algorithms, and Source Code in C, 2nd Ed.", 1996. 376 [RC4-Attack-FMS] 377 Fluhrer, S., Mantin, I., and A. Shamir, "Weaknesses in the 378 Key Scheduling Algorithm of RC4", Selected Areas in 379 Cryptography , 2001. 381 [RC4-Attack-AlF] 382 AlFardan, N., Bernstein, D., Paterson, K., Poettering, B., 383 and J. Schuldt, "On the Security of RC4 in TLS", Usenix 384 Security Symposium 2013, 2013, . 387 [Georgiev2012] 388 Georgiev, M., Iyengar, S., Jana, S., Anubhai, R., Boneh, 389 D., and V. Shmatikov, "The most dangerous code in the 390 world: validating SSL certificates in non-browser 391 software", 2012, 392 . 394 [Attacks-iSec] 395 Sarkar, P. and S. Fitzgerald, "Attacks on SSL, a 396 comprehensive study of BEAST, CRIME, TIME, BREACH, Lucky13 397 and RC4 biases", 8 2013, . 400 [Padding-Oracle] 401 Vaudenay, S., "Security Flaws Induced by CBC Padding 402 Applications to SSL, IPSEC, WTLS...", EUROCRYPT 2002, 403 2002, . 406 [Cross-Protocol] 407 Mavrogiannopoulos, N., Vercauteren, F., Velichkov, V., and 408 B. Preneel, "A cross-protocol attack on the TLS protocol", 409 2012, . 411 [RC4-Attack-Pau] 412 Paul, G. and S. Maitra, "Permutation after RC4 key 413 scheduling reveals the secret key.", 2007, 414 . 417 [RC4-Attack-Man] 418 Mantin, I. and A. Shamir, "A practical attack on broadcast 419 RC4", 2001. 421 [SSL-Stripping] 422 Marlinspike, M., "SSL Stripping", February 2009, 423 . 425 [Bleichenbacher98] 426 Bleichenbacher, D., "Chosen ciphertext attacks against 427 protocols based on the RSA encryption standard pkcs1", 428 1998. 430 [Klima03] Klima, V., Pokorny, O., and T. Rosa, "Attacking RSA-based 431 sessions in SSL/TLS", 2003. 433 [Brumley03] 434 Brumley, D. and D. Boneh, "Remote timing attacks are 435 practical", 2003. 437 [Brubaker2014using] 438 Brubaker, C., Jana, S., Ray, B., Khurshid, S., and V. 439 Shmatikov, "Using frankencerts for automated adversarial 440 testing of certificate validation in SSL/TLS 441 implementations", 2014. 443 [Delignat14] 444 Delignat-Lavaud, A. and K. Bhargavan, "Virtual Host 445 Confusion: Weaknesses and Exploits", Black Hat 2014, 2014. 447 Appendix A. Appendix: Change Log 449 Note to RFC Editor: please remove this section before publication. 451 A.1. draft-ietf-uta-tls-attacks-03 453 o Implemented WG Last Call comments. 455 o Virtual host confusion. 457 o STARTTLS command injection. 459 o Added CVE numbers. 461 A.2. draft-ietf-uta-tls-attacks-02 463 o Added implementation issues ("most dangerous code"), 464 renegotiation, triple handshake. 466 o Added text re: mitigation of Lucky13. 468 o Added applicability to DTLS. 470 A.3. draft-ietf-uta-tls-attacks-01 472 o Added SSL Stripping, attacks related to certificates, Diffie 473 Hellman parameters and denial of service. 475 o Expanded on RC4 attacks, thanks to Andrei Popov. 477 A.4. draft-ietf-uta-tls-attacks-00 479 o Initial version, extracted from draft-sheffer-tls-bcp-01. 481 Authors' Addresses 483 Yaron Sheffer 484 Porticor 485 29 HaHarash St. 486 Hod HaSharon 4501303 487 Israel 489 Email: yaronf.ietf@gmail.com 491 Ralph Holz 492 Technische Universitaet Muenchen 493 Boltzmannstr. 3 494 Garching 85748 495 Germany 497 Email: holz@net.in.tum.de 499 Peter Saint-Andre 500 &yet 502 Email: ietf@stpeter.im