On Fri, Jan 20, 2006 at 10:28:24AM +0100, [EMAIL PROTECTED] via RT wrote:
> ... hmmm, where is the patch ?
I did mail it, and it seems to be in the bug report at:
http://www.aet.tu-cottbus.de/rt2/Ticket/Display.html?id=1204
But it wasn't in the mail send to the list.
I've attached it again.
> I didn't know how to verify the existence or
> not-existence of
> the BUG inside the data ...
The last data of the record should tell how many bytes of padding
there are, and which value they should have. You need to add 1
to the byte to get the number of padding bytes. The i value
above in my mail is how many bytes, ii is the value it should
have.
> Any ideas about compatibility with "older" versions including
> the BUG.
The problem is that _some_ code, seems to send the padding wrong
and have the number of bytes equal to the last byte. The code
assumes that in case the sequence number is 0 and the padding value is
even, so there are an odd number of padding bytes, that the other
end has the bug, and so decreased the number of padding bytes
with 1. My patch now also checks that the byte it assumes isn't
part of the real data is different from the padding byte.
This means that with my patch, there is a 1/256 chance that it
fails to detect that the other side has the bug, where the last
data of the actual data happens to be the same as the padding
byte.
What would be really useful would be some comment/documentation
somewhere that said which software versions are known to have
that bug, and in which version it was fixed.
Kurt
--- ssl/t1_enc.c.old 2006-01-19 21:52:40.000000000 +0100
+++ ssl/t1_enc.c 2006-01-19 21:59:26.000000000 +0100
@@ -632,7 +632,9 @@
{
/* First packet is even in size, so check */
if ((memcmp(s->s3->read_sequence,
- "\0\0\0\0\0\0\0\0",8) == 0) && !(ii &
1))
+ "\0\0\0\0\0\0\0\0",8) == 0) &&
+ !(ii & 1) &&
+ rec->data[l-i] != ii)
s->s3->flags|=TLS1_FLAGS_TLS_PADDING_BUG;
if (s->s3->flags & TLS1_FLAGS_TLS_PADDING_BUG)
i--;
