On Tue, Apr 09, 2002 at 08:52:29PM +0200, David Maurus wrote: > This might have the same cause as the problem I encountered. Brad Whetmore from > Sun helped me find this. > > According to TLS (which can be found e.g. here: > http://www.ietf.org/rfc/rfc2246.txt ), in the final message exchanges from the > TLS handshake, a client key exchange message is sent by the client. The client > key exchange message contains a RSA encrypted premaster secret message, which in > turn contains a field with the "The latest (newest) version supported by the > client.". In case of TLS, this would be 3.1. > > But due to the fact that some older servers did not behave correctly, some SSL > client libraries send the protocol version number as agreed upon in the > handshake (this is wrong according to TLS spec, but compatible to the old > servers). This means they start with a 3.1 ClientHello, and after agreeing on > protocol version 3.0 (SSLv3) they send a premaster secret with 3.0 as the > version number. A correctly implemented TLS server will expect a 3.1 here. [this > would explain the "SSL3_GET_RECORD:wrong version number" error you observed]. In > my case, this wrong version number led to a "bad_record_mac" error as mentioned.
Late versions of OpenSSL provide the SSL_OP_TLS_ROLLBACK_BUG that allows the server to ignore this protocol violation. It is however not enabled by default. Best regards, Lutz -- Lutz Jaenicke [EMAIL PROTECTED] http://www.aet.TU-Cottbus.DE/personen/jaenicke/ BTU Cottbus, Allgemeine Elektrotechnik Universitaetsplatz 3-4, D-03044 Cottbus ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]