[Pkg-openssl-devel] Bug#338006: [openssl.org #1204]: bad record mac because of wrong SSL_OP_TLS_BLOCK_PADDING_BUG handling

[Kurt Roeckx]

Hi,

It seems to me that tls1_enc() is setting
SSL_OP_TLS_BLOCK_PADDING_BUG, while the other side does
not have that bug.

The code looks like this:
                                /* 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))
                                        s->s3->flags|=TLS1_FLAGS_TLS_PADDING_BUG;

The 0.9.8 code seems to compress by default in case that
zlib compression has been added, while 0.9.7 doesn't.
This seems to generate a (compressed) package of size 45
in most cases, but 44 in some cases, depending on the
message being send.

In case it's 45, ii is set to 2 and i to 3, like it
should, but the flags get set to
TLS1_FLAGS_TLS_PADDING_BUG, and i gets decreased to 2.  So
the lenth gets sets to 46 instead of 45.

I can not find a good way to always make sure this
workaround for that bug works proplery, but I think we
should assume there is no bug.  So I propose the attached
patch to fix it.  This should have as effect that in most
case that the bug is present, it still sets the flag, but
it won't in the case were the last byte just happens to be the
same as the padding byte.

This patch fixes it for me, so that two versions with
0.9.8 with zlib compression support can talk to each
other without errors.


Kurt

-------------- next part --------------
--- 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--;