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]
