RE: [openssl.org #1204] bug report - 0.9.8 and bad record mac because of wrong SSL_OP_TLS_BLOCK_PADDING_BUG handling
Hmm, I want to use this for an multi usable web service independent of apache and no restrictions (or so) for the users or user scenarios about openssl usage ... If the caller has an certificate generated by an not-restricted openssl using whatever he want to to ... how can I=web service handle this certificate without getting an bad record mac error ? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of via RT Sent: Saturday, January 07, 2006 3:22 AM To: Kämpfe, Christiane Cc: openssl-dev@openssl.org Subject: [openssl.org #1204] bug report - 0.9.8 and bad record mac because of wrong SSL_OP_TLS_BLOCK_PADDING_BUG handling For Subversion, which goes through apache, I found that one workaround is to disable all SSLv3 ciphers except RC4. My apache config now has: SSLCipherSuite SSLv2:-LOW:-EXPORT:RC4+RSA and subversion appears to work again. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
[openssl.org #1204] bug report - 0.9.8 and bad record mac because of wrong SSL_OP_TLS_BLOCK_PADDING_BUG handling
For Subversion, which goes through apache, I found that one workaround is to disable all SSLv3 ciphers except RC4. My apache config now has: SSLCipherSuite SSLv2:-LOW:-EXPORT:RC4+RSA and subversion appears to work again. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
[openssl.org #1204] bug report - 0.9.8 and bad record mac because of wrong SSL_OP_TLS_BLOCK_PADDING_BUG handling
[EMAIL PROTECTED] - Mon Sep 19 10:05:09 2005]: Hello, I have traced again and found out that c_zlib.c::zlib_compress_block() is responsible that wrec-length is sometimes 44 (korrect value) and sometimes 45 (troublesome value) I'm using zlib 1.2.3 !!! for length 45 I'm getting the trouble with the SSP_OP_TLS_BLOCK_PADDING_BUG handling. Korrekt handling requestor side: length is 44; augmented to 48; -data[47] = 3 provider side: length is 48; decremented with 3+1 = 44 Wrong handling requestor side: length is 45; augmented to 48; -data[47] = 2 provider side: length is 48; decremented with (2+1-1/* PADDING_BUG '\0...' FLAGS..PADDING_BUG */) = 46 !!! I hope this helps - to find out whats going wrong. The bug seems to be reproduced without compression (s_client reports than both Compression and Expansion are equal to 'NONE'). __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
RE: [openssl.org #1204] bug report - 0.9.8 and bad record mac because of wrong SSL_OP_TLS_BLOCK_PADDING_BUG handling
--- see below -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of via RT Sent: Friday, December 02, 2005 2:17 PM To: Kämpfe, Christiane Cc: openssl-dev @openssl.org Subject: [openssl.org #1204] bug report - 0.9.8 and bad record mac because of wrong SSL_OP_TLS_BLOCK_PADDING_BUG handling [EMAIL PROTECTED] - Mon Sep 19 10:05:09 2005]: Hello, I have traced again and found out that c_zlib.c::zlib_compress_block() is responsible that wrec-length is sometimes 44 (korrect value) and sometimes 45 (troublesome value) I'm using zlib 1.2.3 !!! for length 45 I'm getting the trouble with the SSP_OP_TLS_BLOCK_PADDING_BUG handling. Korrekt handling requestor side: length is 44; augmented to 48; -data[47] = 3 provider side: length is 48; decremented with 3+1 = 44 Wrong handling requestor side: length is 45; augmented to 48; -data[47] = 2 provider side: length is 48; decremented with (2+1-1/* PADDING_BUG '\0...' FLAGS..PADDING_BUG */) = 46 !!! I hope this helps - to find out whats going wrong. The bug seems to be reproduced without compression (s_client reports than both Compression and Expansion are equal to 'NONE'). I'm sorry, I don't understand your remark. I was stepping also inside the compression handling called by openssl ! I have now made the same tests with an openssl produced without compression abilities (no-zlib). This works fine. openssl with compression still doesn't work with zlib 1.2.3. By the way, why couldn't I change the compression level for openssl compression ? ... we'v got via gSOAP the best performance results with level 1 in combination with HTTP chunking. - c.kae __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
RE: [openssl.org #1204] bug report - 0.9.8 and bad record mac because of wrong SSL_OP_TLS_BLOCK_PADDING_BUG handling
Greetings! On Fri, 2 Dec 2005, [EMAIL PROTECTED] via RT wrote: The bug seems to be reproduced without compression (s_client reports than both Compression and Expansion are equal to 'NONE'). I'm sorry, I don't understand your remark. I was stepping also inside the compression handling called by openssl ! I have now made the same tests with an openssl produced without compression abilities (no-zlib). This works fine. openssl with compression still doesn't work with zlib 1.2.3. By the way, why couldn't I change the compression level for openssl compression ? ... we'v got via gSOAP the best performance results with level 1 in combination with HTTP chunking. I've reproduced this bug with s_client and apache as server requesting page which requires client certificate. So I'm not sure that this bug is completely zlib-related. -- SY, Dmitry Belyavsky (ICQ UIN 6575) __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
RE: [openssl.org #1204] bug report - 0.9.8 and bad record mac because of wrong SSL_OP_TLS_BLOCK_PADDING_BUG handling
Greetings! On Fri, 2 Dec 2005, [EMAIL PROTECTED] via RT wrote: The bug seems to be reproduced without compression (s_client reports than both Compression and Expansion are equal to 'NONE'). I'm sorry, I don't understand your remark. I was stepping also inside the compression handling called by openssl ! I have now made the same tests with an openssl produced without compression abilities (no-zlib). This works fine. openssl with compression still doesn't work with zlib 1.2.3. By the way, why couldn't I change the compression level for openssl compression ? ... we'v got via gSOAP the best performance results with level 1 in combination with HTTP chunking. I've reproduced this bug with s_client and apache as server requesting page which requires client certificate. So I'm not sure that this bug is completely zlib-related. -- SY, Dmitry Belyavsky (ICQ UIN 6575) __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
RE: [openssl.org #1204] bug report - 0.9.8 and bad record mac because of wrong SSL_OP_TLS_BLOCK_PADDING_BUG handling
Greetings back ! -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dmitry Belyavsky via RT Sent: Friday, December 02, 2005 2:45 PM To: Kämpfe, Christiane Cc: openssl-dev@openssl.org Subject: RE: [openssl.org #1204] bug report - 0.9.8 and bad record mac because of wrong SSL_OP_TLS_BLOCK_PADDING_BUG handling Greetings! On Fri, 2 Dec 2005, [EMAIL PROTECTED] via RT wrote: The bug seems to be reproduced without compression (s_client reports than both Compression and Expansion are equal to 'NONE'). I'm sorry, I don't understand your remark. I was stepping also inside the compression handling called by openssl ! ... snip/ I've reproduced this bug with s_client and apache as server requesting page which requires client certificate. So I'm not sure that this bug is completely zlib-related. -- SY, Dmitry Belyavsky (ICQ UIN 6575) Aah, now I understand a little bit more. .. requires client certificates ... so both sides use OpenSSL ?. OpenSSL is normaly produced using compression even if you don't notice this - beginning with the handshakes ! So I'm not sure if your bug is completely unconnected with zlib. By the way - do you know the versions of zlib used on both sides ? __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
RE: [openssl.org #1204] bug report - 0.9.8 and bad record mac because of wrong SSL_OP_TLS_BLOCK_PADDING_BUG handling
Greetings! On Fri, 2 Dec 2005, [EMAIL PROTECTED] via RT wrote: I've reproduced this bug with s_client and apache as server requesting page which requires client certificate. So I'm not sure that this bug is completely zlib-related. Aah, now I understand a little bit more. .. requires client certificates ... so both sides use OpenSSL ?. OpenSSL is normaly produced using compression even if you don't notice this - beginning with the handshakes ! So I'm not sure if your bug is completely unconnected with zlib. By the way - do you know the versions of zlib used on both sides ? 1.2.2-4.sarge.2 on client side 1.2.3-8 and 1.2.2-4.sarge.2 on different server. -- SY, Dmitry Belyavsky (ICQ UIN 6575) __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
RE: [openssl.org #1204] bug report - 0.9.8 and bad record mac because of wrong SSL_OP_TLS_BLOCK_PADDING_BUG handling
Greetings! On Fri, 2 Dec 2005, [EMAIL PROTECTED] via RT wrote: I've reproduced this bug with s_client and apache as server requesting page which requires client certificate. So I'm not sure that this bug is completely zlib-related. Aah, now I understand a little bit more. .. requires client certificates ... so both sides use OpenSSL ?. OpenSSL is normaly produced using compression even if you don't notice this - beginning with the handshakes ! So I'm not sure if your bug is completely unconnected with zlib. By the way - do you know the versions of zlib used on both sides ? 1.2.2-4.sarge.2 on client side 1.2.3-8 and 1.2.2-4.sarge.2 on different server. -- SY, Dmitry Belyavsky (ICQ UIN 6575) __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
