Re: CBC vulnerability workaround
On Wed, Jul 03, 2002 at 09:54:15AM -0400, Jeffrey Altman wrote: Is there a summary somewhere of the changes that were made to the SSLv3 and TLSv1 message exchanges to avoid the vulnerability in the CBC cipher suites? I'm not aware of a proper summary of all the issues involved. In particular, I need to know: . the description of the vulnerability There's something at the following URLs: http://www.imc.org/ietf-tls/mail-archive/msg03273.html http://www.imc.org/ietf-tls/mail-archive/msg03387.html . a description of the workaround From CHANGES: *) Implement a countermeasure against a vulnerability recently found in CBC ciphersuites in SSL 3.0/TLS 1.0: Send an empty fragment before application data chunks to avoid the use of known IVs with data potentially chosen by the attacker. [Bodo Moeller] As the protocols don't explicitly reset CBC IVs, the IV for each block is known in advance (it's the last ciphertext block from the previous record). The attack works by choosing application data with knowledge of the IV that will be used for encrypting this data. Empty fragments (i.e. fragments with plaintext length zero) ensure that the known IV will not be used for application data, and that an unpredictable IV will be in use when the actual application data is processed in the following fragment. . a summary of why the workaround should be considered valid in the protocol I have found nothing in the SSL 3.0 and TLS 1.0 specifications that forbids fragments of length zero. The length is given as a 'uint16' value; the specification defines upper limits, but no lower limits. draft-freier-ssl-version3-02.txt (SSL 3.0): 5.2.1 Fragmentation The record layer fragments information blocks into SSLPlaintext records of 2^14 bytes or less. [...] RFC 2246 (TLS 1.0): 6.2.1. Fragmentation The record layer fragments information blocks into TLSPlaintext records carrying data in chunks of 2^14 bytes or less. [...] I have come across a large commercial user of SSL services for whom the workaround fails. The transmission of the data frame with no application data generates an SSL Alert causing the application to close the connection. The developers of the SSL library being used have replied that SSLv3 does not permit data frames containing no application data. Can they cite a particular provision in the specification that forbids records with a fragment length of zero? I haven't found one, and length-zero fragments are handled well by many implementations (including Microsoft IIS). But I am aware of compatibility problems. One way to avoid these is to use RC4 (which does not need the workaround). Also new OpenSSL versions (starting with 0.9.6e or 0.9.7) have an option for disabling the countermeasure, which is automatically enabled in many applications; from CHANGES: *) New option SSL_OP_DONT_INSERT_EMPTY_FRAGMENTS for disabling the SSL 3.0/TLS 1.0 CBC vulnerability countermeasure that was added in OpenSSL 0.9.6d. As the countermeasure turned out to be incompatible with some broken SSL implementations, the new option is part of SSL_OP_ALL. SSL_OP_ALL is usually employed when compatibility with weird SSL implementations is desired (e.g. '-bugs' option to 's_client' and 's_server'), so the new option is automatically set in many applications. [Bodo Moeller] -- Bodo Möller [EMAIL PROTECTED] PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html * TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt * Tel. +49-6151-16-6628, Fax +49-6151-16-6036 __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: CBC vulnerability workaround
I have found nothing in the SSL 3.0 and TLS 1.0 specifications that forbids fragments of length zero. The length is given as a 'uint16' value; the specification defines upper limits, but no lower limits. draft-freier-ssl-version3-02.txt (SSL 3.0): 5.2.1 Fragmentation The record layer fragments information blocks into SSLPlaintext records of 2^14 bytes or less. [...] RFC 2246 (TLS 1.0): 6.2.1. Fragmentation The record layer fragments information blocks into TLSPlaintext records carrying data in chunks of 2^14 bytes or less. [...] I have come across a large commercial user of SSL services for whom the workaround fails. The transmission of the data frame with no application data generates an SSL Alert causing the application to close the connection. The developers of the SSL library being used have replied that SSLv3 does not permit data frames containing no application data. Can they cite a particular provision in the specification that forbids records with a fragment length of zero? I haven't found one, and length-zero fragments are handled well by many implementations (including Microsoft IIS). Bodo: Thanks for the reply. They are quoting: draft-netscape-ssl-v2 1.1 SSL Record Header Format In SSL, all data sent is encapsulated in a record, an object which is composed of a header and some non-zero amount of data RFC2246 6.2. Record layer The TLS Record Layer receives uninterpreted data from higher layers in non-empty blocks of arbitrary size. Jeffrey Altman * Sr.Software Designer Kermit 95 2.0 GUI available now!!! The Kermit Project @ Columbia University SSH, Secure Telnet, Secure FTP, HTTP http://www.kermit-project.org/Secured with MIT Kerberos, SRP, and [EMAIL PROTECTED] OpenSSL. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: CBC vulnerability workaround
On Wed, Jul 03, 2002 at 12:07:01PM -0400, Jeffrey Altman wrote: Can they cite a particular provision in the specification that forbids records with a fragment length of zero? I haven't found one, and length-zero fragments are handled well by many implementations (including Microsoft IIS). [...] They are quoting: draft-netscape-ssl-v2 1.1 SSL Record Header Format In SSL, all data sent is encapsulated in a record, an object which is composed of a header and some non-zero amount of data Note that this is from the SSL 2.0 draft, it has nothing to do with SSL 3.0. (And anyway it does not say anything about the amount of *application* data -- it mentions the header, so the 'non-zero amount of data' is all the bytes that appear after the header, not just what is left after decryption). The SSL 3.0 draft is similar to RFC 2246. RFC2246 6.2. Record layer The TLS Record Layer receives uninterpreted data from higher layers in non-empty blocks of arbitrary size. This wording only refers to the interface between the SSL/TLS record layer and higher layers. These 'blocks' are virtual items, they are not actual protocol data. When we look at how the record layer arranges the data, we are talking about 'fragments', not 'blocks'. RFC 2246 says that the 'blocks' are 'non-empty', but otherwise 'of arbitrary size'. Certainly the latter does not apply to fragments, so there is no reason to conclude that the former does -- not even by analogy. This is the next paragraph from RFC 2246: 6.2.1. Fragmentation The record layer fragments information blocks into TLSPlaintext records carrying data in chunks of 2^14 bytes or less. Client message ^^ boundaries are not preserved in the record layer (i.e., multiple client messages of the same ContentType may be coalesced into a single TLSPlaintext record, or a single message may be fragmented ^^ across several records). ^^ When OpenSSL inserts an empty fragment, it fragments a single message into multiple parts, the first of which happens to be empty. I concede that this might appear pointless as long as one doesn't know about the CBC security issues, but nothing in the specification speaks against it. (And, of course, security considerations speak for it.) -- Bodo Möller [EMAIL PROTECTED] PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html * TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt * Tel. +49-6151-16-6628, Fax +49-6151-16-6036 __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: CBC vulnerability workaround
When OpenSSL inserts an empty fragment, it fragments a single message into multiple parts, the first of which happens to be empty. I concede that this might appear pointless as long as one doesn't know about the CBC security issues, but nothing in the specification speaks against it. (And, of course, security considerations speak for it.) -- Bodo Möller [EMAIL PROTECTED] Thanks Bodo. This is exactly the response I needed. Jeffrey Altman * Sr.Software Designer Kermit 95 2.0 GUI available now!!! The Kermit Project @ Columbia University SSH, Secure Telnet, Secure FTP, HTTP http://www.kermit-project.org/Secured with MIT Kerberos, SRP, and [EMAIL PROTECTED] OpenSSL. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
