idnits 2.17.1 draft-mrex-tls-secure-renegotiation-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) 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 == Line 519 has weird spacing: '...ionType rene...' -- Couldn't find a document date in the document -- date freshness check skipped. -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 4346 (Obsoleted by RFC 5246) ** Obsolete normative reference: RFC 2246 (Obsoleted by RFC 4346) -- Obsolete informational reference (is this intentional?): RFC 2818 (Obsoleted by RFC 9110) Summary: 4 errors (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT Martin Rex 3 Updates (if approved): 5246, 4366, 4346, 2246 (SAP AG) 4 Intended Status: Standards Track Stefan Santesson 5 Expires: June 18, 2010 (3xA Security) 6 December 15, 2009 8 Transport Layer Security (TLS) Secure Renegotiation 9 11 Status of this Memo 13 This Internet-Draft is submitted to IETF in full conformance with the 14 provisions of BCP 78 and BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that other 18 groups may also distribute working documents as Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/1id-abstracts.html 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html 31 Copyright and License Notice 33 Copyright (c) 2009 IETF Trust and the persons identified as the 34 document authors. All rights reserved. 36 This document is subject to BCP 78 and the IETF Trust's Legal 37 Provisions Relating to IETF Documents 38 (http://trustee.ietf.org/license-info) in effect on the date of 39 publication of this document. Please review these documents 40 carefully, as they describe your rights and restrictions with respect 41 to this document. Code Components extracted from this document must 42 include Simplified BSD License text as described in Section 4.e of 43 the Trust Legal Provisions and are provided without warranty as 44 described in the BSD License. 46 Abstract 48 A protocol design flaw in the TLS renegotiation handshake leaves all 49 currently implemented protocol version of TLS (SSLv3 to TLSv1.2) 50 vulnerable to Man-in-the-Middle (MitM) attacks where the attacker can 51 establish a TLS session with a server, send crafted application data 52 of his choice to the server and then proxy an unsuspecting client's 53 TLS handshake into the TLS renegotiation handshake of the server. 54 Many applications on top of TLS see the data injected by the attacker 55 and the data sent by the client as a single data stream and assume 56 that an authentication during the TLS renegotiation handshake or 57 contained in the client's application data applies to the entire data 58 stream received through the TLS-protected communication channel. 60 This document describes a protocol change for all protocol versions 61 of TLS and SSLv3 that will fix this vulnerability for all 62 communication between updated TLS clients and updated TLS servers. 64 Table of Contents 66 1 Requirements Terminology . . . . . . . . . . . . . . . . . . . . 3 67 2 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 3 68 2.1 TLS handshake terminology . . . . . . . . . . . . . . . . . 3 69 3 The TLS renegotiation vulnerability . . . . . . . . . . . . . . 4 70 3.1 Attack scenarios . . . . . . . . . . . . . . . . . . . . . 4 71 4 The TLS renegotiation fix . . . . . . . . . . . . . . . . . . . 6 72 4.1 Characteristics . . . . . . . . . . . . . . . . . . . . . . 6 73 4.2 Solution brief . . . . . . . . . . . . . . . . . . . . . . 6 74 4.3 Additional connection and session state . . . . . . . . . . 7 75 4.4 New protocol elements . . . . . . . . . . . . . . . . . . . 8 76 4.5 Reconnaissance . . . . . . . . . . . . . . . . . . . . . . 9 77 4.6 Backwards interoperability with old peers . . . . . . . . . 9 78 4.7 Updated Handshake message hash calculation . . . . . . . 10 79 4.8 Rationale . . . . . . . . . . . . . . . . . . . . . . . . 11 80 5 Security Considerations . . . . . . . . . . . . . . . . . . . 11 81 6 IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 82 7 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 83 8 References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 84 8.1 Normative References . . . . . . . . . . . . . . . . . . 13 85 8.2 Informative References . . . . . . . . . . . . . . . . . 13 86 Appendix A Implementation Considerations . . . . . . . . . . . . 14 87 A.1 Forward compatibility of SSLv3 and TLSv1.0 . . . . . . . 14 88 A.2 Installed Base Considerations . . . . . . . . . . . . . . 14 89 Appendix B Code example . . . . . . . . . . . . . . . . . . . . 15 90 B.1 Server-Side, updated handshake message hash . . . . . . . 15 91 Author's Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 93 1 Requirements Terminology 95 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 96 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 97 document are to be interpreted as described in RFC 2119 [RFC2119]. 99 2 Introduction 101 The TLS protocol provides communications security over the Internet 102 and allows client/server applications to communicate in a way that is 103 designed to prevent eavesdropping, tampering, or message forgery. 105 TLS is the IETF's successor to SSLv3 from Netscape. TLSv1.0 [RFC2246] 106 was finalized in January 1999. It is widely deployed and used to 107 protect the communication of many application protocols, such as HTTP 108 over TLS [RFC2818], WebDAV, CalDAV, LDAP, SOAP, SIP, IPP, IMAP/POP, 109 NNTP, SMTP, XMPP, BEEP and also SSL-VPNs. 111 Today you find SSL and its successor TLS not only in web servers and 112 web browsers, but in many communication software for PCs, networking 113 equipment, appliances, PDAs, SmartPhones and other small devices. 115 2.1 TLS handshake terminology 117 The TLS and SSLv3 protocols specify only two types of handshakes (see 118 TLSv1.2 [RFC5246] Section 7.3 Handshake Protocol Overview), a "full 119 handshake" and an "abbreviated handshake" which is also referred to 120 as "session resume". 122 The distinction "initial TLS handshake" and "TLS renegotiation 123 handshake" is orthogonal to these handshake types. 125 An initial TLS handshake is the first TLS handshake on a connection, 126 i.e. the handshake begins in the clear; the TLS record layer is 127 initialized with the cipher suite TLS_NULL_WITH_NULL_NULL. 129 A TLS renegotiation handshake is a handshake that is started under 130 the protection of an existing TLS session. With the exchange of the 131 ChangeCipherSuite messages the existing TLS session is entirely 132 replaced with the newly (re)negotiated TLS session. 134 3 The TLS renegotiation vulnerability 136 All currently existing protocol version of TLS (SSLv3 to TLSv1.2) 137 contain a security vulnerability in the design of the TLS 138 renegotiation algorithm. The newly renegotiated TLS session is 139 completely independent from the previous TLS session that it 140 replaces. Applications using TLS to secure their communication often 141 use TLS for channel authentication. They assume that an 142 authentication performed at the TLS level or within application data 143 coming through the TLS-protected channel is valid for all data 144 received through this channel. The TLS protocol explicitly requires a 145 TLS renegotiation to be mostly transparent to the application data 146 stream. This opens a door to Man-in-the-Middle (MitM) attacks 147 exploiting this weakness in the TLS renegotiation handshake. 149 3.1 Attack scenarios 151 There are three possible types of attack scenarios on TLS 152 renegotiation: 154 1. Client's initial TLS handshake is proxied by MitM into Server's 155 TLS renegotiation 157 2. Client's renegotiation handshake is proxied by MitM into 158 Server's initial TLS handshake 160 3. Two independent TLS sessions Client<->MitM and MitM<->Server 161 are spliced into one single TLS session Client<->Server through 162 TLS renegotiation where the MitM proxies all communication 164 The MitM can only inject data into the initial TLS session where it 165 is an original TLS client or server. It is not possible to modify 166 the actual handshake between TLS client and server without breaking 167 the Finished verification. As soon as the ChangeCipherSpec messages 168 are exchanged on the renegotiation handshake, the MitM can no longer 169 inject or read application data exchanged by client and server. So 170 the MitM is unable to read the server's reply to the injected 171 request(s) that the unsuspecting client is made to authenticate for. 173 It is impossible for the server to notice that it is being attacked 174 in all three scenarios with the existing TLS protocol. Example 175 exploits for type (1) scenarios have received the most attention, and 176 are quite effective for protocols such as HTTP over TLS. When client 177 certificates are used, type (3) attacks are also attractive. For 178 type (2) scenarios, no attractive exploits have been described so 179 far, but it would be unwise to assume that they do not exist. 181 At the TLS protocol level, all these renegotiations look perfectly 182 OK. Server Endpoint Identification performed by clients (as in 183 Section 3.1 of [RFC2818]) does not necessarily mitigate all of the 184 attacks scenarios of type (2) and (3), where the renegotiation will 185 usually result in a change of the server identity at the TLS protocol 186 level. The TLS protocol itself does not constrain changes in 187 cryptographic properties and authenticated identities during a 188 renegotiation. 190 A MitM attack usually leaves behind _two_ victims of the attack. The 191 server is a victim of the attack, because it is made to perform a 192 request issued by the attacker. But the client is also a victim, 193 because the authentication performed by the unsuspecting client is 194 re-purposed to authorize the request of the attacker. 196 You may notice that TLS clients in type (1) scenarios as well as TLS 197 servers in type (2) scenarios perform only an initial TLS handshake, 198 and they can still become a victim of an attack. This has serious 199 consequences. It means that all TLS implementations, including those 200 that have renegotiation disabled or not even implemented, are at risk 201 from becoming a victim in a MitM attack on the TLS renegotiation 202 vulnerability. 204 4 The TLS renegotiation fix 206 4.1 Characteristics 208 If a TLS client or server wants to be absolutely sure that it can not 209 become a victim of an attack based on the TLS renegotiation 210 vulnerability, it (a) must be updated and (b) must discontinue 211 talking TLS to peers that are not updated. 213 The latter is a pretty challenging requirement. The first one 214 getting updated would suddenly have no one else to talk to. In the 215 interest of continuous operation and interoperability with existing 216 usage scenarios in the installed base, the vast majority is likely to 217 embrace a different approach--at least for a transition period, where 218 a lot of communication peers are not yet updated. Unpatched TLS 219 server should have the old renegotiation disabled entirely. TLS 220 clients, which have traditionally been quite trusting to TLS servers 221 and requests for renegotiation, should become much more careful about 222 unpatched TLS servers they handshake with. 224 This document provides a protocol fix for the TLS renegotiation 225 vulnerability. It secures the TLS renegotiation between updated 226 clients and updated servers. It allows updated clients and servers 227 to determine whether their respective communication peer has also 228 been updated. It provides a high level of interoperability with the 229 installed base of old TLS communication peers, while protecting 230 communication between updated TLS peers from downgrade attacks. 232 4.2 Solution brief 234 This solution applies equally to TLS and SSLv3. All further 235 references to TLS without protocol version applies to SSLv3 as well. 237 1. The verify_data from Finished messages of a TLS handshake are 238 memorized in the connection state and will be added into the 239 handshake message hash of the renegotiation handshake, thus 240 authenticating the enclosing TLS session. 242 2. For Client to Server signaling, the special cipher suite value 243 TLS_RENEGO_PROTECTION_REQUEST is assigned and must be included 244 in all ClientHello handshake messages from updated clients. 246 3. For Server to Client signaling, a new TLS extension 247 "renego_protection" is defined, that an updated Server must 248 send back as a ServerHello extension whenever it finds the 249 cipher suite value TLS_RENEGO_PROTECTION_REQUEST in 250 ClientHello. 252 4.3 Additional connection and session state 254 In order to implement secure TLS renegotiation, it is necessary to 255 memorize additional TLS connection state: the verify_data from the 256 finished messages, a state variable "protection_available" for the 257 signaling, and optionally a session state variable "allow_old_renego" 258 when old renegotiation needs to be supported. 260 The length of the verify_data in the Finished messages differs 261 between protocol versions of TLSv1.x and SSLv3: 263 TLSv1.0 & TLSv1.1: 12 octets 264 TLSv1.2: default 12 octets --but can be defined by cipher suite 265 SSLv3: 36 octets --it is a concatenation of two 266 elements "md5_hash" and "sha_hash" 268 The additional state that TLS client and servers have to memorize: 270 (1a) plaintext verify_data of Client.Finished 271 (1b) length of (1a) 272 (2a) plaintext verify_data of Server.Finished 273 (2b) length of (2a) 274 (3) protection_available /*Boolean, for handshake signaling */ 276 (4) allow_old_renego /*Boolean, OPTIONAL session attribute*/ 277 /*for renegotiation with old TLS peers*/ 279 For every initial TLS handshake (see Section 2.1), the values for 280 (1a)(1b)(2a)(2b) are empty/initial. The the optional session state 281 "allow_old_renego" is left unchanged when a session resume is 282 performed, and initialized with the setting of a system-wide or 283 application-supplied value for support of old renegotiation 284 (distinguishing client and server) for a full initial TLS handshake. 285 "protection_available" is initialized to False for every TLS 286 handshake. 288 TLS servers and clients that implement renegotiation MUST memorize 289 the verify_data of Client and Server Finished messages, so this can 290 be used in a later renegotiation handshake to authenticate the 291 enclosing TLS session. These could be memorized when building one's 292 own Finished message and when processing the peer's Finished message. 294 If TLS implementations want to offer support for old renegotiation, 295 at least for the transition period, then any system-wide 296 configuration option(s) MUST distinguish between TLS server and TLS 297 client side. TLS servers SHOULD NOT allow old renegotiation, TLS 298 client MAY allow old renegotiation for a transition period, after 299 which they SHOULD NOT allow old renegotiation. 301 4.4 New protocol elements 303 This document defines a new cipher suite value 305 TLS_RENEGO_PROTECTION_REQUEST = { TBD, TBD } 307 to be used as for Client to Server signaling in ClientHello. This 308 cipher suite value does _not_ represent a real cipher suite and 309 SHOULD NOT be configurable by, and not made visible to, regular 310 cipher suite configuration APIs and UIs. TLS servers MUST NOT select 311 this cipher suite value as the common cipher suite with the client. 313 This document also defines a new TLS extension "renego_protection" 315 enum { 316 renego_protection(TBD), (65535) 317 } ExtensionType; 319 and contains _no_ extension_data (zero-length vector) 321 Implementations of SSLv3 and TLSv1.x, which do not implement TLS 322 extensions, might use the following simplified approach to process 323 the Server to Client signaling in ServerHello. Properly encoded, the 324 above TLS extension is represented with the following static sequence 325 of 6 octets as a single TLS extension in ServerHello after 326 compression_method: 328 0x00 0x04 MSB LSB 0x00 0x00 330 where (MSB*256)+LSB is equal to the extension type assigned by IANA. 332 Conforming servers that do not implement TLS extensions may add this 333 static sequence of 6 octets into the ServerHello handshake message 334 after compression_methods as a response to a ClientHello that 335 includes TLS_RENEGO_PROTECTION_REQUEST. (this increases the length of 336 the ServerHello handshake message from 70 to 76 octets, in case of a 337 32-octet session_id). 339 Conforming clients that do not implement TLS extensions will have to 340 check whether the received ServerHello handshake message contains 6 341 additional octets after the compression_method and whether these 342 match the above static 6-octet sequence representing the TLS 343 extension "renego_protection". 345 4.5 Reconnaissance 347 All conforming TLS clients MUST include the cipher suite value 348 TLS_RENEGO_PROTECTION_REQUEST in the cipher_suites list of _every_ 349 ClientHello handshake message they send. This includes clients that 350 do not implement renegotiation or have it disabled (see Section 3.1 351 type (1) attacks). This cipher suite value MAY appear anywhere in the 352 cipher_suites list. 354 Conforming clients that compose a ClientHello handshake messages with 355 other TLS extensions, MAY include the TLS extension 356 "renego_protection" defined in 4.4. 358 When receiving a ClientHello that contains the cipher suite value 359 TLS_RENEGO_PROTECTION_REQUEST, conforming servers MUST treat this 360 exactly like the receipt of the TLS extension "protection_available" 361 and MUST add this TLS extension into the (Extended)ServerHello reply 362 to the client. This applies to full handshakes as well as session 363 resume, and includes servers that do not implement renegotiation or 364 have it disabled (see Section 3.1 type (2) attacks). 366 Such server behavior is an explicit exception to the prohibition of 367 "unsolicited" ServerHello extensions in Section 7.4.1.4 [RFC5246] and 368 Section 2.3 [RFC4366] and is only permitted when the client requests 369 this TLS extension by including the TLS_RENEGO_PROTECTION_REQUEST 370 cipher suite value in ClientHello. The special cipher suite value is 371 a request for the renego_protection extension that can be combined 372 with extension-less ClientHello and initial SSLv2 ClientHello that 373 are still in use by conservative clients and for re-connect fallbacks 374 of some web browsers for interoperability with old servers. 376 A conforming server which receives TLS_RENEGO_PROTECTION_REQUEST 377 asserts the "protection_available" flag in the connection state and 378 sets the optional "allow_old_renego" state to False. 380 A conforming client that receives an (Extended)ServerHello containing 381 the "renego_protection" extension asserts the "protection_available" 382 flag in the connection state and sets the optional "allow_old_renego" 383 state to False for the current session. 385 4.6 Backwards interoperability with old peers 387 Conforming TLS clients receiving a ServerHello without the TLS 388 extension "renego_protection" assume an old server. If the current 389 handshake is a renegotiation for the TLS client, but 390 "allow_old_renego" is False for the enclosing TLS session, then the 391 client MUST abort the handshake with a fatal handshake failure alert. 393 Otherwise the client MAY proceed with the old handshake. 395 Conforming TLS servers receiving a ClientHello without the cipher 396 suite value TLS_RENEGO_PROTECTION_REQUEST assume an old client. If 397 the current handshake is a renegotiation for the TLS server, but 398 "allow_old_renego" is False for the enclosing TLS session, then the 399 server MUST abort the handshake with a fatal handshake failure alert. 400 Otherwise the server MAY proceed with the old handshake. 402 4.7 Updated Handshake message hash calculation 404 For all TLS handshakes between updated clients and updated servers 405 the following updated definition of the handshake message hash is 406 used. This applies to the handshake message hash used in 407 Client.Finished and Server.Finished and in the optional 408 CertificateVerify handshake message. 410 The updated handshake message hash will ensure that initial and 411 renegotiation handshakes are properly distinguished from each other 412 and that renegotiation handshakes must authenticate the enclosing TLS 413 session. 415 Conforming clients and servers, which have received the confirmation 416 about renego protection availability from their peer, MUST add the 417 following data directly to their handshake message hash function, 418 immediately following the ServerHello handshake message: 420 on every initial TLS handshake with an updated peer: 422 4 static octets: 0x14 0x00 0x00 0x0b 424 on every TLS renegotiation handshake with an updated peer: 426 4 static octets: 0x14 0xff 0xff 0xff 427 verify_data from Client.Finished of enclosing TLS session 428 verify_data from Server.Finished of enclosing TLS session 430 This applies to full TLS handshake as well as TLS session resumes. 432 The verify_data from Client.Finished MUST be added before the 433 verify_data from Server.Finished. There MUST NOT be any length 434 fields included in verify_data, only the verify_data itself (so for 435 TLSv1.0-1.2 it is 12 octets each, for SSLv3 36 octets each). 437 The optional state "allow_old_renego" must be transferred from the 438 enclosing TLS session to the newly renegotiated session. 440 4.8 Rationale 442 The renegotiation vulnerability is removed by cryptographically 443 binding the renegotiation handshake to the enclosing TLS session. 444 This is accomplished by both sides adding the Finished.verify_data, 445 which authenticated the enclosing TLS session, to the handshake 446 message hash of the renegotiation handshake. The handshake 447 authentication performed by the Finished message verification will 448 fail if client and server do not share the exact same memories about 449 the previous Finished messages, and thus protect renegotiation 450 handshakes from MitM attacks. The same applies to the 451 CertificateVerify signature verification in the optional client 452 certificate authentication. 454 As discussed in Section 3.1, only communication between updated 455 clients and updated servers can be reliably protected from type (1) 456 and (2) attacks. Clients and servers need a bidirectional signaling 457 scheme as part of the TLS handshake to determine whether the peer, 458 they are handshaking with, is also updated. 460 The chosen signaling scheme is a compromise due to a non-negligible 461 amount of intolerance of old servers to TLS extensions in the 462 ClientHello handshake message. Various workarounds currently in use 463 to remedy this interoperability problem (see [RFC5246] Appendix E) 464 can not be simply ignored. The chosen signaling scheme works for 465 extension-less SSLv3 ClientHello and even SSLv2 ClientHello on the 466 initial TLS handshake. This enables secure renegotiation in all 467 existing usage scenarios, including conservative clients and 468 application-level reconnect fallbacks. 470 5 Security Considerations 472 This document describes a protocol change for all currently existing 473 versions of the TLS protocol: TLSv1.2 [RFC5246], TLSv1.1 [RFC4346], 474 TLSv1.0 [RFC2246] and SSLv3 [SSLv3] to fix a serious security 475 vulnerability in the TLS renegotiation algorithm. 477 The original SSL and TLS protocol does not distinguish an initial TLS 478 handshake from a TLS renegotiation handshake. Every pair of old TLS 479 clients and servers of the installed base can potentially become a 480 victim in a Man-in-the-Middle (MitM) attack through TLS renegotiation 481 in one or more of the attack scenarios described in Section 3.1, 482 provided that one of the two implements TLS renegotiation and can be 483 coerced, lured, or simply asked to perform a TLS renegotiation. 485 Only TLS communication between updated clients and updated servers is 486 reliably protected from the risk of attack. 488 Usually TLS renegotiation involves a full TLS handshake, so all of 489 the security parameters and cryptographic properties are newly 490 negotiated and authenticated, including the identities of the 491 communication peers. Some applications actively use this feature, 492 e.g. web servers deciding to request client certificates in a server- 493 initiated TLS renegotiation after having seen the client's HTTP 494 request. Some applications may be actively using the possibility to 495 switch identities multiple times through TLS renegotiation for an 496 existing connection. 498 To a number of applications, however, the change of a previously 499 authenticated identity during TLS renegotiation comes as a surprise, 500 and this may have serious security implications. Some TLS 501 implementations will automatically perform certificate path 502 validation, but the interpretation what a peer's certificate means is 503 left entirely to the calling application ([RFC5246] Section 1. last 504 paragraph). 506 It is RECOMMENDED that TLS implementations offer to applications the 507 option to either disable renegotiation or to abort renegotiations 508 when the remote peer tries to replace a previously authenticated 509 certificate with a different one during renegotiation. 511 6 IANA Considerations 513 IANA has assigned the following TLS Cipher Suite value and the 514 following TLS ExtensionType value for use with this specification 515 (see Section 4.4): 517 TLS Cipher Suite TLS_RENEGO_PROTECTION_REQUEST = { TBD, TBD } 519 TLS ExtensionType renego_protection = { TBD } 521 7 Acknowledgements 523 The TLS renegotiation vulnerability was first discovered by Marsh Ray 524 in August 2009. The MitM susceptibility of the TLS renegotiation was 525 independently discovered by Martin Rex in November 2009 during 526 channel bindings discussions on the IETF TLS WG mailing list. 528 Many participants of the TLS working group provided valuable feedback 529 and comments for improvement, to make the fix easy to implement and 530 have a low risk of causing interoperability problems. 532 Special thanks to Michael D'Errico for continuous implementer's 533 feedback, Marsh Ray, Nicolas Williams, Nasko Oskov, David-Sarah 534 Hopwood and Eric Rescorla for elaborate discussions and input. 536 8 References 537 8.1 Normative References 539 [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate 540 Requirement Levels", BCP 14, RFC 2119, March 1997. 542 [RFC5246] T. Dierks and E. Rescorla, "The Transport Layer Security 543 (TLS) Protocol Version 1.2", RFC 5246, August 2008 545 [RFC4346] T. Dierks and E. Rescorla, "The Transport Layer Security 546 (TLS) Protocol Version 1.1", RFC 4346, April 2006 548 [RFC2246] T. Dierks and C. Allen, "The TLS Protocol Version 1.0", 549 RFC 2246, January 1999 551 NOTE to implementers: The protocol specifications of TLSv1.2, TLSv1.1 552 and TLSv1.0 are individually referenced. Please refer to the protocol 553 specification on which your implementation is based when implementing 554 the fix described in this document. There were a few backwards 555 incompatible changes in the TLS protocol specifications that may not 556 be sufficiently obvious to spot. 558 8.2 Informative References 560 [SSLv3] Alan O. Freier, Philip Karlton, Paul C. Kocher, "The SSL 561 Protocol Version 3.0", Internet Draft, November 1996, 562 http://tools.ietf.org/html/draft-ietf-tls-ssl-version3-00 564 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000 566 [RFC4366] S. Blake-Wilson, M. Nystrom, D. Hopwood, J. Mikkelsen, T. 567 Wright, "Transport Layer Security (TLS) Extensions", 568 RFC 4466, April 2006 570 Appendix A Implementation Considerations 572 A.1 Forward compatibility of SSLv3 and TLSv1.0 574 The evolvement of the TLS protocol is facing problems with the 575 interoperability of newer protocol features with some server 576 implementations of SSLv3 and TLSv1.0 in the installed base. 578 There are two areas of big concern, where minimal changes to the code 579 might make a huge difference in terms of interoperability. These two 580 issues are described in a little more detail in [RFC5246] Appendix E. 582 One problem is some servers (lack of) forward compatibility for extra 583 data in the ClientHello handshake message (the extensibility used by 584 TLS extensions). The other is forward interoperability with TLS 585 protocol version numbers other than SSLv3 {0x03,0x00} or TLSv1.0 586 {0x03,0x01} in ClientHello.client_version and the relation to 587 protocol versions in other handshake messages (ServerHello, RSA 588 Premaster Secret) and in the SSL/TLS record layer. 590 When updating SSLv3 or TLSv1.0 code for implementing this fix, it is 591 highly advisable to also check these two issues. 593 A.2 Installed Base Considerations 595 Over the last 14 years SSLv3 and TLS have grown a huge installed 596 base, but differing characteristics with respect to supported 597 protocol versions, and forward compatibility of protocol versions and 598 TLS extension in the initial ClientHello handshake message. 600 Some of the installed base is quite old, some might be out of 601 maintenance, and some will be difficult to patch, let alone upgrade. 603 The production of software patches with the security fix for 604 TLS/SSLv3 described in this document will be followed by a transition 605 period where the patches get individually deployed, resulting in a 606 mix of updated and old TLS client and servers. Adoption speed will 607 likely correspond to the number of interoperability problems and 608 risks each patch creates for existing usage scenarios. 610 Implementers, software vendors and suppliers should be careful with 611 providing the update/patch in a fashion that will adversely affect 612 existing usage scenarios. Many consumers of the TLS and SSL 613 technology will likely need a configuration option that lets them 614 individually determine when to discontinue SSL/TLS-protected 615 communication with unpatched TLS peers, for continued operation 616 through the transition period. 618 Appendix B Code example 620 B.1 Server-Side, updated handshake message hash 622 Here is an example, very loosely based on OpenSSL, for the server- 623 side of the updated handshake message algorithm. 625 The final statement in ssl/s3_srvr.c:ssl3_send_server_hello() 627 return(ssl3_do_write(s,SSL3_RT_HANDSHAKE)); 629 could be replaced with something like the following: 631 ret = ssl3_do_write(s,SSL3_RT_HANDSHAKE); 632 if ( ret>0 ) 633 { 634 if (s->s3->protection_available) 635 { 636 if (NULL == s->enc_read_ctx) 637 { 638 /* add distinct prefix for initial handshake */ 639 ssl3_finished_mac(s,"\x14\x00\x00\x0b", 4); 640 } 641 else 642 { 643 /* add static prefix for renegotiation */ 644 ssl3_finished_mac(s,"\x14\xff\xff\xff", 4); 645 /* add previous verify_data of Client.Finished */ 646 ssl3_finish_mac(s,s->s3->previous_client_finished, 647 s->s3->previous_client_finished_len); 648 /* add previous verify_data of Server.Finished */ 649 ssl3_finish_mac(s,s->s3->previous_server_finished, 650 s->s3->previous_server_finished_len); 651 } 652 } 653 else 654 { 655 if (NULL != s->enc_read_ctx) 656 if (!s->session->allow_old_renego) 657 { 658 ssl3_send_alert(s,SSL3_AL_FATAL, 659 SSL_AD_HANDSHAKE_FAILURE); 660 ret = -1; 661 } 662 } 663 } 664 } 665 return(ret); 667 Author's Addresses 669 Martin Rex 670 SAP AG 671 EMail: mrex@sap.com 673 Stefan Santesson 674 3xA Security 675 EMail: sts@aaa-sec.com