idnits 2.17.1
draft-ietf-uta-tls-attacks-05.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 (October 23, 2014) is 3473 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-05
== Outdated reference: A later version (-01) exists of
draft-ietf-tls-prohibiting-rc4-00
== Outdated reference: A later version (-10) exists of
draft-ietf-tls-negotiated-ff-dhe-02
Summary: 0 errors (**), 0 flaws (~~), 4 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 26, 2015 TUM
6 P. Saint-Andre
7 &yet
8 October 23, 2014
10 Summarizing Known Attacks on TLS and DTLS
11 draft-ietf-uta-tls-attacks-05
13 Abstract
15 Over the last few years there have been several serious attacks on
16 Transport Layer Security (TLS), including attacks on its most
17 commonly used ciphers and modes of operation. This document
18 summarizes these attacks, with the goal of motivating generic and
19 protocol-specific recommendations on the usage of TLS and Datagram
20 TLS (DTLS).
22 Status of This Memo
24 This Internet-Draft is submitted in full conformance with the
25 provisions of BCP 78 and BCP 79.
27 Internet-Drafts are working documents of the Internet Engineering
28 Task Force (IETF). Note that other groups may also distribute
29 working documents as Internet-Drafts. The list of current Internet-
30 Drafts is at http://datatracker.ietf.org/drafts/current/.
32 Internet-Drafts are draft documents valid for a maximum of six months
33 and may be updated, replaced, or obsoleted by other documents at any
34 time. It is inappropriate to use Internet-Drafts as reference
35 material or to cite them other than as "work in progress."
37 This Internet-Draft will expire on April 26, 2015.
39 Copyright Notice
41 Copyright (c) 2014 IETF Trust and the persons identified as the
42 document authors. All rights reserved.
44 This document is subject to BCP 78 and the IETF Trust's Legal
45 Provisions Relating to IETF Documents
46 (http://trustee.ietf.org/license-info) in effect on the date of
47 publication of this document. Please review these documents
48 carefully, as they describe your rights and restrictions with respect
49 to this document. Code Components extracted from this document must
50 include Simplified BSD License text as described in Section 4.e of
51 the Trust Legal Provisions and are provided without warranty as
52 described in the Simplified BSD License.
54 Table of Contents
56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
57 2. Attacks on TLS . . . . . . . . . . . . . . . . . . . . . . . 3
58 2.1. SSL Stripping . . . . . . . . . . . . . . . . . . . . . . . 3
59 2.2. STARTTLS Command Injection Attack (CVE-2011-0411) . . . . . 3
60 2.3. BEAST (CVE-2011-3389) . . . . . . . . . . . . . . . . . . . 4
61 2.4. Padding Oracle Attacks . . . . . . . . . . . . . . . . . . 4
62 2.5. Attacks on RC4 . . . . . . . . . . . . . . . . . . . . . . 4
63 2.6. Compression Attacks: CRIME, TIME and BREACH . . . . . . . . 5
64 2.7. Certificate and RSA-Related Attacks . . . . . . . . . . . . 5
65 2.8. Theft of RSA Private Keys . . . . . . . . . . . . . . . . . 6
66 2.9. Diffie-Hellman Parameters . . . . . . . . . . . . . . . . . 6
67 2.10. Renegotiation (CVE-2009-3555) . . . . . . . . . . . . . . . 6
68 2.11. Triple Handshake (CVE-2014-1295) . . . . . . . . . . . . . 6
69 2.12. Virtual Host Confusion . . . . . . . . . . . . . . . . . . 7
70 2.13. Denial of Service . . . . . . . . . . . . . . . . . . . . . 7
71 2.14. Implementation Issues . . . . . . . . . . . . . . . . . . . 7
72 2.15. Usability . . . . . . . . . . . . . . . . . . . . . . . . . 8
73 3. Applicability to DTLS . . . . . . . . . . . . . . . . . . . . 8
74 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
75 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8
76 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8
77 7. Informative References . . . . . . . . . . . . . . . . . . . 9
78 Appendix A. Appendix: Change Log . . . . . . . . . . . . . . . . 12
79 A.1. draft-ietf-uta-tls-attacks-05 . . . . . . . . . . . . . . . 13
80 A.2. draft-ietf-uta-tls-attacks-04 . . . . . . . . . . . . . . . 13
81 A.3. draft-ietf-uta-tls-attacks-03 . . . . . . . . . . . . . . . 13
82 A.4. draft-ietf-uta-tls-attacks-02 . . . . . . . . . . . . . . . 13
83 A.5. draft-ietf-uta-tls-attacks-01 . . . . . . . . . . . . . . . 13
84 A.6. draft-ietf-uta-tls-attacks-00 . . . . . . . . . . . . . . . 13
85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13
87 1. Introduction
89 Over the last few years there have been several major attacks on
90 Transport Layer Security (TLS) [RFC5246], including attacks on its
91 most commonly used ciphers and modes of operation. Details are given
92 in Section 2, but a quick summary is that both AES-CBC and RC4, which
93 together make up for most current usage, have been seriously attacked
94 in the context of TLS.
96 This situation was one of the motivations for the creation of the UTA
97 working group, which was tasked with the creation of generic and
98 protocol-specific recommendations for the use of TLS along with
99 Datagram TLS (DTLS) [RFC6347] (unless otherwise noted under
100 Section 3, all of the information provided in this document applies
101 to DTLS).
103 "Attacks always get better; they never get worse" (ironically, this
104 saying is attributed to the U.S. National Security Agency, the NSA).
105 This attacks summarized in this document reflect our knowledge as of
106 this writing. It seems likely that new attacks will be discovered in
107 the future.
109 For a more detailed discussion of the attacks listed here, the
110 interested reader is referred to [Attacks-iSec].
112 2. Attacks on TLS
114 This section lists the attacks that motivated the current
115 recommendations in [I-D.ietf-uta-tls-bcp]. This list is not intended
116 to be an extensive survey of the security of TLS.
118 While there are widely deployed mitigations for some of the attacks
119 listed below, we believe that their root causes necessitate a more
120 systematic solution, which we have attempted to develop in
121 [I-D.ietf-uta-tls-bcp].
123 When an identifier exists for an attack, we have included its CVE
124 (Common Vulnerabilities and Exposures) ID. CVE [CVE] is an
125 extensive, industry-wide database of software vulnerabilities.
127 2.1. SSL Stripping
129 Various attacks attempt to remove the use of SSL/TLS altogether, by
130 modifying unencrypted protocols that request the use of TLS,
131 specifically modifying HTTP traffic and HTML pages as they pass on
132 the wire. These attacks are known collectively as SSL Stripping (a
133 form of the more generic "downgrade attack") and were first
134 introduced by Moxie Marlinspike [SSL-Stripping]. In the context of
135 Web traffic, these attacks are only effective if the client initially
136 accesses a Web server using HTTP. A commonly used mitigation is HTTP
137 Strict Transport Security (HSTS) [RFC6797].
139 2.2. STARTTLS Command Injection Attack (CVE-2011-0411)
141 Similarly, there are attacks on the transition between unprotected
142 and TLS-protected traffic. A number of IETF application protocols
143 have used an application-level command, usually STARTTLS, to upgrade
144 a clear-text connection to use TLS. Multiple implementations of
145 STARTTLS had a flaw where an application-layer input buffer retained
146 commands that were pipelined with the STARTTLS command, such that
147 commands received prior to TLS negotiation are executed after TLS
148 negotiation. This problem is resolved by requiring the application-
149 level command input buffer to be empty before negotiating TLS. Note
150 that this flaw lives in the application layer code and does not
151 impact the TLS protocol directly.
153 STARTLS and similar mechanisms are vulnerable to downgrade attacks
154 whereby the attacker simply removes the STARTTLS indication from the
155 (unprotected) request. This cannot be mitigated unless HSTS-like
156 solutions are added.
158 2.3. BEAST (CVE-2011-3389)
160 The BEAST attack [BEAST] uses issues with the TLS 1.0 implementation
161 of CBC (that is, the predictable initialization vector) to decrypt
162 parts of a packet, and specifically to decrypt HTTP cookies when HTTP
163 is run over TLS.
165 2.4. Padding Oracle Attacks
167 A consequence of the MAC-then-encrypt design in all current versions
168 of TLS is the existence of padding oracle attacks [Padding-Oracle].
169 A recent incarnation of these attacks is the Lucky Thirteen attack
170 (CVE-2013-0169) [CBC-Attack], a timing side-channel attack that
171 allows the attacker to decrypt arbitrary ciphertext.
173 The Lucky Thirteen attack can be mitigated by using authenticated
174 encryption like AES-GCM [RFC5288] or encrypt-then-mac
175 [I-D.ietf-tls-encrypt-then-mac] instead of the TLS default of MAC-
176 then-encrypt.
178 An even newer variant of the padding oracle attack, one that does not
179 use timing information, is the POODLE attack (CVE-2014-3566) [POODLE]
180 on SSL 3.0. This attack has no known mitigation.
182 2.5. Attacks on RC4
184 The RC4 algorithm [RC4] has been used with TLS (and previously, SSL)
185 for many years. RC4 has long been known to have a variety of
186 cryptographic weaknesses, e.g. [RC4-Attack-Pau], [RC4-Attack-Man],
187 [RC4-Attack-FMS]. Recent cryptanalysis results [RC4-Attack-AlF]
188 exploit biases in the RC4 keystream to recover repeatedly encrypted
189 plaintexts.
191 These recent results are on the verge of becoming practically
192 exploitable; currently they require 2^26 sessions or 13x2^30
193 encryptions. As a result, RC4 can no longer be seen as providing a
194 sufficient level of security for TLS sessions. For further details,
195 the reader is referred to [I-D.ietf-tls-prohibiting-rc4] and the
196 references it cites.
198 2.6. Compression Attacks: CRIME, TIME and BREACH
200 The CRIME attack [CRIME] (CVE-2012-4929) allows an active attacker to
201 decrypt ciphertext (specifically, cookies) when TLS is used with TLS
202 level compression.
204 The TIME attack [TIME] and the later BREACH attack [BREACH] (CVE-
205 2013-3587, though the number has not been officially allocated) both
206 make similar use of HTTP-level compression to decrypt secret data
207 passed in the HTTP response. We note that compression of the HTTP
208 message body is much more prevalent than compression at the TLS
209 level.
211 The former attack can be mitigated by disabling TLS compression. We
212 are not aware of mitigations at the TLS protocol level to the latter
213 attack, and so application-level mitigations are needed (see
214 [BREACH]). For example, implementations of HTTP that use CSRF tokens
215 will need to randomize them. Even the best practices and
216 recommendations from [I-D.ietf-uta-tls-bcp] are insufficient to
217 thwart this attack.
219 2.7. Certificate and RSA-Related Attacks
221 There have been several practical attacks on TLS when used with RSA
222 certificates (the most common use case). These include
223 [Bleichenbacher98] and [Klima03]. While the Bleichenbacher attack
224 has been mitigated in TLS 1.0, the Klima attack relies on a version-
225 check oracle is only mitigated by TLS 1.1.
227 The use of RSA certificates often involves exploitable timing issues
228 [Brumley03] (CVE-2003-0147), unless the implementation takes care to
229 explicitly eliminate them.
231 A recent certificate fuzzing tool [Brubaker2014using] uncovered
232 numerous vulnerabilities in different TLS libraries, related to
233 certificate validation.
235 2.8. Theft of RSA Private Keys
237 When TLS is used with most non-Diffie Hellman cipher suites, it is
238 sufficient to obtain the server's private key in order to decrypt any
239 sessions (past and future) that were initiated with that server.
240 This technique is used, for example, by the popular Wireshark network
241 sniffer to inspect TLS-protected connections.
243 It is known that stolen (or otherwise obtained) private keys have
244 been used as part of large-scale monitoring [RFC7258] of certain
245 servers.
247 Such attacks can be mitigated by better protecting the private key,
248 e.g. using OS protections or dedicated hardware. Even more effective
249 is the use of cipher suites that offer "forward secrecy", the
250 property that revealing a secret such as a private key does not
251 expose past or future sessions to a passive attacker.
253 2.9. Diffie-Hellman Parameters
255 TLS allows the definition of ephemeral Diffie-Hellman and Elliptic
256 Curve Diffie-Hellman parameters in its respective key exchange modes.
257 This results in an attack detailed in [Cross-Protocol]. Using
258 predefined DH groups, as proposed in
259 [I-D.ietf-tls-negotiated-ff-dhe], would mitigate this attack.
261 In addition, clients that do not properly verify the received
262 parameters are exposed to man in the middle (MITM) attacks.
263 Unfortunately the TLS protocol does not mandate this verification
264 (see [RFC6989] for analogous information for IPsec).
266 2.10. Renegotiation (CVE-2009-3555)
268 A major attack on the TLS renegotiation mechanism applies to all
269 current versions of the protocol. The attack and the TLS extension
270 that resolves it are described in [RFC5746].
272 2.11. Triple Handshake (CVE-2014-1295)
274 The triple handshake attack [BhargavanDFPS14] enables the attacker to
275 cause two TLS connections to share keying material. This leads to a
276 multitude of attacks, e.g. Man-in-the-Middle, breaking safe
277 renegotiation, and breaking channel binding via TLS Exporter
278 [RFC5705] or "tls-unique" [RFC5929].
280 2.12. Virtual Host Confusion
282 A recent article [Delignat14] describes a security issue whereby
283 SSLv3 fallback and improper handling of session caches on the server
284 side can be abused by an attacker to establish a malicious connection
285 to a virtual host other than the one originally intended and approved
286 by the server. This attack is especially serious in performance
287 critical environments where sharing of SSLv3 session caches is very
288 common.
290 2.13. Denial of Service
292 Server CPU power has progressed over the years so that TLS can now be
293 turned on by default. However, the risk of malicious clients and
294 coordinated groups of clients ("botnets") mounting denial of service
295 attacks is still very real. TLS adds another vector for
296 computational attacks, since a client can easily (with little
297 computational effort) force the server to expend relatively large
298 computational work. It is known that such attacks have in fact been
299 mounted.
301 2.14. Implementation Issues
303 Even when the protocol is properly specified, this does not guarantee
304 the security of implementations. In fact there are very common
305 issues that often plague TLS implementations. In particular, when
306 integrating into higher-level protocols, TLS and its PKI-based
307 authentication are sometimes the source of misunderstandings and
308 implementation "shortcuts". An extensive survey of these issues can
309 be found in [Georgiev2012].
311 o Implementations might omit validation of the server certificate
312 altogether. For example, this is true of the default
313 implementation of HTTP client libraries in Python 2 (see e.g.
314 CVE-2013-2191).
316 o Implementations might not validate the server identity. This
317 validation typically amounts to matching the protocol-level server
318 name with the certificate's Subject Alternative Name field. Note:
319 this same information is often also found in the Common Name part
320 of the Distinguished Name, and some validators incorrectly
321 retrieve it from there instead of from the Subject Alternative
322 Name.
324 o Implementations might validate the certificate chain incorrectly
325 or not at all, or use an incorrect or outdated trust anchor list.
327 An implementation attack of a different kind, one that exploits a
328 simple coding mistake (bounds check), is the Heartbleed attack (CVE-
329 2014-0160) that affected a wide swath of the Internet when it was
330 discovered in April 2014.
332 2.15. Usability
334 Many TLS endpoints, such as browsers and mail clients, allow the user
335 to explicitly accept an invalid server certificate. This often takes
336 the form of a UI dialog (e.g., "do you accept this server?") and
337 users have been conditioned to respond in the affirmative in order to
338 allow the connection to take place.
340 This user behavior is used by (arguably legitimate) "SSL proxies"
341 that decrypt and re-encrypt the TLS connection in order to enforce
342 local security policy. It is also abused by attackers whose goal is
343 to gain access to the encrypted information.
345 Mitigation is complex and will probably involve a combination of
346 protocol mechanisms (HSTS, certificate pinning
347 [I-D.ietf-websec-key-pinning]) and very careful UI design.
349 3. Applicability to DTLS
351 DTLS [RFC4347] [RFC6347] is an adaptation of TLS for UDP.
353 With respect to the attacks described in the current document, DTLS
354 1.0 is equivalent to TLS 1.1. The only exception is RC4, which is
355 disallowed in DTLS. DTLS 1.2 is equivalent to TLS 1.2.
357 4. IANA Considerations
359 This document requires no IANA actions. [Note to RFC Editor: please
360 remove this whole section before publication.]
362 5. Security Considerations
364 This document describes protocol attacks in an informational manner,
365 and in itself does not have any security implications. Its companion
366 documents, especially [I-D.ietf-uta-tls-bcp], certainly do.
368 6. Acknowledgments
370 We would like to thank Stephen Farrell, Simon Josefsson, John
371 Mattsson, Yoav Nir, Kenny Paterson, Patrick Pelletier, Tom Ritter,
372 Rich Salz and Meral Shirazipour for their feedback on this document.
373 We thank Andrei Popov for contributing text on RC4, Kohei Kasamatsu
374 for text on Lucky13, Ilari Liusvaara for text on attacks and on DTLS,
375 Aaron Zauner for text on virtual host confusion, and Chris Newman for
376 text on STARTTLS command injection.
378 During IESG review, Richard Barnes, Barry Leiba, and Kathleen
379 Moriarty caught several issues that needed to be addressed.
381 The authors gratefully acknowledge the assistance of Leif Johansson
382 and Orit Levin as the working group chairs and Pete Resnick as the
383 sponsoring Area Director.
385 The document was prepared using the lyx2rfc tool, created by Nico
386 Williams.
388 7. Informative References
390 [RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
391 Security", RFC 4347, April 2006.
393 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
394 (TLS) Protocol Version 1.2", RFC 5246, August 2008.
396 [RFC5288] Salowey, J., Choudhury, A., and D. McGrew, "AES Galois
397 Counter Mode (GCM) Cipher Suites for TLS", RFC 5288,
398 August 2008.
400 [RFC5705] Rescorla, E., "Keying Material Exporters for Transport
401 Layer Security (TLS)", RFC 5705, March 2010.
403 [RFC5746] Rescorla, E., Ray, M., Dispensa, S., and N. Oskov,
404 "Transport Layer Security (TLS) Renegotiation Indication
405 Extension", RFC 5746, February 2010.
407 [RFC5929] Altman, J., Williams, N., and L. Zhu, "Channel Bindings
408 for TLS", RFC 5929, July 2010.
410 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
411 Security Version 1.2", RFC 6347, January 2012.
413 [RFC6797] Hodges, J., Jackson, C., and A. Barth, "HTTP Strict
414 Transport Security (HSTS)", RFC 6797, November 2012.
416 [RFC6989] Sheffer, Y. and S. Fluhrer, "Additional Diffie-Hellman
417 Tests for the Internet Key Exchange Protocol Version 2
418 (IKEv2)", RFC 6989, July 2013.
420 [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an
421 Attack", BCP 188, RFC 7258, May 2014.
423 [I-D.ietf-uta-tls-bcp]
424 Sheffer, Y., Holz, R., and P. Saint-Andre,
425 "Recommendations for Secure Use of TLS and DTLS", draft-
426 ietf-uta-tls-bcp-05 (work in progress), October 2014.
428 [I-D.ietf-tls-prohibiting-rc4]
429 Popov, A., "Prohibiting RC4 Cipher Suites", draft-ietf-
430 tls-prohibiting-rc4-00 (work in progress), July 2014.
432 [I-D.ietf-tls-encrypt-then-mac]
433 Gutmann, P., "Encrypt-then-MAC for TLS and DTLS", draft-
434 ietf-tls-encrypt-then-mac-03 (work in progress), July
435 2014.
437 [I-D.ietf-tls-negotiated-ff-dhe]
438 Gillmor, D., "Negotiated Finite Field Diffie-Hellman
439 Ephemeral Parameters for TLS", draft-ietf-tls-negotiated-
440 ff-dhe-02 (work in progress), October 2014.
442 [I-D.ietf-websec-key-pinning]
443 Evans, C., Palmer, C., and R. Sleevi, "Public Key Pinning
444 Extension for HTTP", draft-ietf-websec-key-pinning-21
445 (work in progress), October 2014.
447 [CVE] MITRE, , "Common Vulnerabilities and Exposures",
448 .
450 [CBC-Attack]
451 AlFardan, N. and K. Paterson, "Lucky Thirteen: Breaking
452 the TLS and DTLS Record Protocols", IEEE Symposium on
453 Security and Privacy , 2013.
455 [BEAST] Rizzo, J. and T. Duong, "Browser Exploit Against SSL/TLS",
456 2011, .
459 [POODLE] Moeller, B., Duong, T., and K. Kotowicz, "This POODLE
460 Bites:Exploiting the SSL 3.0 Fallback", 2014,
461 .
463 [CRIME] Rizzo, J. and T. Duong, "The CRIME Attack", EKOparty
464 Security Conference 2012, 2012.
466 [BREACH] Prado, A., Harris, N., and Y. Gluck, "The BREACH Attack",
467 2013, .
469 [TIME] Be'ery, T. and A. Shulman, "A Perfect CRIME? Only TIME
470 Will Tell", Black Hat Europe 2013, 2013,
471 .
474 [RC4] Schneier, B., "Applied Cryptography: Protocols,
475 Algorithms, and Source Code in C, 2nd Ed.", 1996.
477 [RC4-Attack-FMS]
478 Fluhrer, S., Mantin, I., and A. Shamir, "Weaknesses in the
479 Key Scheduling Algorithm of RC4", Selected Areas in
480 Cryptography , 2001.
482 [RC4-Attack-AlF]
483 AlFardan, N., Bernstein, D., Paterson, K., Poettering, B.,
484 and J. Schuldt, "On the Security of RC4 in TLS", Usenix
485 Security Symposium 2013, 2013,
486 .
489 [Georgiev2012]
490 Georgiev, M., Iyengar, S., Jana, S., Anubhai, R., Boneh,
491 D., and V. Shmatikov, "The most dangerous code in the
492 world: validating SSL certificates in non-browser
493 software", 2012,
494 .
496 [Attacks-iSec]
497 Sarkar, P. and S. Fitzgerald, "Attacks on SSL, a
498 comprehensive study of BEAST, CRIME, TIME, BREACH, Lucky13
499 and RC4 biases", 8 2013,
500 .
503 [Padding-Oracle]
504 Vaudenay, S., "Security Flaws Induced by CBC Padding
505 Applications to SSL, IPSEC, WTLS...", EUROCRYPT 2002,
506 2002, .
509 [Cross-Protocol]
510 Mavrogiannopoulos, N., Vercauteren, F., Velichkov, V., and
511 B. Preneel, "A cross-protocol attack on the TLS protocol",
512 2012, .
514 [RC4-Attack-Pau]
515 Paul, G. and S. Maitra, "Permutation after RC4 key
516 scheduling reveals the secret key.", 2007,
517 .
520 [RC4-Attack-Man]
521 Mantin, I. and A. Shamir, "A practical attack on broadcast
522 RC4", 2001.
524 [SSL-Stripping]
525 Marlinspike, M., "SSL Stripping", February 2009,
526 .
528 [Bleichenbacher98]
529 Bleichenbacher, D., "Chosen ciphertext attacks against
530 protocols based on the RSA encryption standard pkcs1",
531 1998.
533 [Klima03] Klima, V., Pokorny, O., and T. Rosa, "Attacking RSA-based
534 sessions in SSL/TLS", 2003.
536 [Brumley03]
537 Brumley, D. and D. Boneh, "Remote timing attacks are
538 practical", 2003.
540 [Brubaker2014using]
541 Brubaker, C., Jana, S., Ray, B., Khurshid, S., and V.
542 Shmatikov, "Using frankencerts for automated adversarial
543 testing of certificate validation in SSL/TLS
544 implementations", 2014.
546 [Delignat14]
547 Delignat-Lavaud, A. and K. Bhargavan, "Virtual Host
548 Confusion: Weaknesses and Exploits", Black Hat 2014, 2014.
550 [BhargavanDFPS14]
551 Bhargavan, K., Delignat-Lavaud, A., Fournet, C., Pironti,
552 A., and P. Strub, "Triple handshakes and cookie cutters:
553 breaking and fixing authentication over tls", 2014,
554 .
557 Appendix A. Appendix: Change Log
559 Note to RFC Editor: please remove this section before publication.
561 A.1. draft-ietf-uta-tls-attacks-05
563 o Implemented Gen-ART and IESG reviews.
565 A.2. draft-ietf-uta-tls-attacks-04
567 o Implemented AD review comments.
569 A.3. draft-ietf-uta-tls-attacks-03
571 o Implemented WG Last Call comments.
573 o Virtual host confusion.
575 o STARTTLS command injection.
577 o Added CVE numbers.
579 A.4. draft-ietf-uta-tls-attacks-02
581 o Added implementation issues ("most dangerous code"),
582 renegotiation, triple handshake.
584 o Added text re: mitigation of Lucky13.
586 o Added applicability to DTLS.
588 A.5. draft-ietf-uta-tls-attacks-01
590 o Added SSL Stripping, attacks related to certificates, Diffie
591 Hellman parameters and denial of service.
593 o Expanded on RC4 attacks, thanks to Andrei Popov.
595 A.6. draft-ietf-uta-tls-attacks-00
597 o Initial version, extracted from draft-sheffer-tls-bcp-01.
599 Authors' Addresses
601 Yaron Sheffer
602 Porticor
603 29 HaHarash St.
604 Hod HaSharon 4501303
605 Israel
607 Email: yaronf.ietf@gmail.com
608 Ralph Holz
609 Technische Universitaet Muenchen
610 Boltzmannstr. 3
611 Garching 85748
612 Germany
614 Email: holz@net.in.tum.de
616 Peter Saint-Andre
617 &yet
619 Email: peter@andyet.com
620 URI: https://andyet.com/