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]
