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]

Reply via email to