---> 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]
