I and others took a closer look at this, and it appears that there is no bug in the OpenSSL implementation after all. So please close this bug report.
The problem was caused by the fact that the server was incorrectly using the padding style used by SSL instead of the one that must be used with TLS1 (page 20 of the RFC2246). Sorry about this invalid bug report, Fabrice Ferino. --- Richard Levitte via RT <[EMAIL PROTECTED]> wrote: > > All right, I think that the problem lies in > tls1_enc(), and I'm assuming > it's the pad-checking part (the end) that goofs up. > > The indication I have is the following: > > [EMAIL PROTECTED] - Sat Nov 29 22:02:53 2003]: > > > If you run the s_client program (compiled with the > > change above and TLS_DEBUG #define'd) using the > > following arguments: > > > > -msg -tls1 > > > > and connecting to a SSL server that will select > the > > TLS_RSA_WITH_3DES_EDE_CBC_SHA cipher suite, the > TLS > > handshake will work properly until the OpenSSL > client > > receives the Finished message sent by the server. > This > > is the output of the s_client executable at this > > point: > > > > ---------- > > tls1_enc(0) > > > EVP_Cipher(ds=00918B90,rec->data=009F55F5,rec->input=009F55F5,l=40) > > ==> > > EVP_CIPHER_CTX: 0 buf_len, 24 key_len [8 128], 8 > > iv_len > > IV: 1D44982C1B69A80E > > rec->input= 0a b6 20 43 0c 28 c3 04 a9 73 fe eb > c3 74 > > 38 d1 e9 60 da f3 0b 0a 26 25 fc af 2c 51 b2 db 0a > 8b > > bb a4 0f 78 29 e5 5d 06 > > rec->data= 14 00 00 0c 77 f3 c1 07 53 b8 5f 4f 9c > 15 > > b2 fe 96 af 5e f3 5e 32 a7 29 a1 0f 5b 88 8d 6b 67 > d7 > > dd 6b b9 0f 00 01 02 03 > > dec 40 > > 14 00 00 0C 77 F3 C1 07 53 B8 5F 4F 9C 15 B2 FE > > 96 AF 5E F3 5E 32 A7 29 A1 0F 5B 88 8D 6B 67 D7 > > DD 6B B9 0F 00 01 02 03 > > sec=4E 0E 1E 13 E9 F6 98 69 12 A5 65 79 0C 37 B5 > CB 5B > > 2B 12 D5 > > seq=00 00 00 00 00 00 00 00 > > buf=16 03 01 00 14 > > rec=14 00 00 0C 77 F3 C1 07 53 B8 5F 4F 9C 15 B2 > FE 96 > > AF 5E F3 > > > > --------------- > > See the line saying "dec 40"? That's in > ssl3_get_record() (s3_pkt.c: > 366), just a few lines after tls1_enc() has been > called (through the > pointer ->enc). 40 is the length of the record as > returned by > tls1_enc(), and at this point, it's obvious it > didn't subtract the > padding length from the total length (which is > originally 40 as well). > > I'd like to ask you to try to figure out why the > padding isn't counted. > Can you do that? > > -- > Richard Levitte > [EMAIL PROTECTED] ===== __________________________________ Do you Yahoo!? Find out what made the Top Yahoo! Searches of 2003 http://search.yahoo.com/top2003 ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
