Hi, The current declaration of a i2d function is: #define DECLARE_ASN1_ENCODE_FUNCTIONS(type, itname, name) \ ... \ int i2d_##name(type *a, unsigned char **out); \ ...
Shouldn't it be: #define DECLARE_ASN1_ENCODE_FUNCTIONS(type, itname, name) \ ... \ int i2d_##name(const type *a, unsigned char **out); \ ... Same thing for the implementation. Best regards, Frédéric Giudicelli http://www.newpki.org ----- Original Message ----- From: "Fabrice Ferino via RT" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Friday, January 02, 2004 3:08 AM Subject: Re: [openssl.org #763] Bug report: Incorrect MAC check of the Server Finished message if TLS1 with a block cipher > > 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] > ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
