I'm not entirely sure what you're talking about here. Mind you, I don't know the code in the ssl/ directory, so bear with me for being clumsy.
Anyway, looking at tls1_mac(), it doesn't look like it assumes anything about the message size. The size it *returns* entirely depends on the hash algorithm used by HMAC. Since you avoided saying which cipher suite was actually chosen, it's a little hard to know what to expect. The "TripleDES cipher" suites available with OpenSSL are the following (at least on my system): EDH-RSA-DES-CBC3-SHA SSLv3 Kx=DH Au=RSA Enc=3DES(168) Mac=SHA1 EDH-DSS-DES-CBC3-SHA SSLv3 Kx=DH Au=DSS Enc=3DES(168) Mac=SHA1 DES-CBC3-SHA SSLv3 Kx=RSA Au=RSA Enc=3DES(168) Mac=SHA1 DES-CBC3-MD5 SSLv2 Kx=RSA Au=RSA Enc=3DES(168) Mac=MD5 Note that almost all of them use SHA1 as a hash algorithm, which does (correctly) produce a 20-byte hash, resulting in a 20-byte output from tls1_mac(). Now, maybe you're talking about the content of the Finished message. The content (called verify_data in RFC 2246) should be 12 bytes, not 16. The resulting data that tls1_mac() ends up processing (as far as I understand) should be 25 bytes (it adds a 8-byte sequence counter and 5 bytes containing the record type, the TLS version and the length). Please expand, and perhaps reanalyse your situation. Could it be that the server does something wrong? [EMAIL PROTECTED] - Thu Nov 13 08:26:17 2003]: > This can be seen with version 0.9.7a and 0.9.7c (only > versions I checked): Run openssl s_client -tls1 with a > SSL server that will choose one of the TripleDES > cipher suites. > > The Finished message sent by the server at the end of > the handshake is incorrectly rejected by the OpenSSL > implementation. > > Compiling SSL 0.9.7c with #define TLS1_DEBUG, it seems > the problem is the following: > the tl1_mac() routine computes the MAC incorrectly: > the TLS1 Finished message is always 16 bytes long, > however the tl1_mac computes the expected MAC thinking > the message is 20 bytes long:it uses 20 bytes of the > message (including the first 4 bytes of the sent MAC) > and the length used in the first part of the MAC input > is also set to 20. The MAC generated is incorrect, > does not match the MAC sent by the server and > therefore the handshake fails. > > It's possible the length problem is related to the > fact that the padding for the Finished message will be > 4 bytes long (20 bytes padded to 24 to make 3 blocks > of 8 bytes for encryption by 3-DES). > > Note that the MAC generated for the client Finished > message is correct, so it seems the problem is in the > arguments sent to tls1_mac() when processing a > received Finished message. > > Apologies if this is a well-known problem, I could not > find any reference to it in the RT system, except > maybe the problem reported by Tim Tassonis recently. > > Regards, > > Fabrice Ferino. > > __________________________________ > Do you Yahoo!? > Protect your identity with Yahoo! Mail AddressGuard > http://antispam.yahoo.com/whatsnewfree > -- Richard Levitte [EMAIL PROTECTED] ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
