Claus Assmann wrote:
>
> Hi! At least some "good" news: I found the bug. Here's the problem
> description again:
>
> (starttls to connect to mail.stalker.com, using OpenSSL 0.9.5a)
>
> ! According to the SSL/TLS standard, the first 2 bytes of that secret
> ! should be the protocol version. Since CgatePro insists on TLSv0 (aka
> ! SSL 3.0), the OpenSSL correctly switches to that protocol. But - forgets
> ! about it in the premaster secret: the first 2 bytes there show "3" "1",
> ! instead of "3" "0".
>
> ! Everywhere within the *protocol* itself, OpenSSL
> ! properly switches to SSL v3 and uses 3.0 everywhere. BUT. There is a thing
> ! called "premaster secret". NOT the protocol block that exchange that secret -
> ! that block correctly contains the 3.0 version tag. The "premaster secret"
> ! itself (when decoded) is a 48 byte "random" number. But this number should
> ! have 2 first bytes fixed. And those bytes should be 3 and 0 - i.e. the same as
> ! the version bytes in the protocol blocks.
>
> The problem is in s3_clnt.c around line 1345:
> tmp_buf[0]=s->client_version>>8;
> tmp_buf[1]=s->client_version&0xff;
> in function ssl3_send_client_key_exchange(SSL *s)
>
> s->client_version has the value 0x0301, but it should have 0x0300
> according to Stalker.
>
> Can please someone with more inside knowledge verify this and apply
> the proper patch?
>
Its not apparent that this actually *is* a bug. If you examine the SSLv3
spec:
> 5.6.7.1 RSA encrypted premaster secret message
>
> If RSA is being used for key agreement and authentication, the
> client generates a 48-byte pre-master secret, encrypts it under the
> public key from the server's certificate or temporary RSA key from
> a server key exchange message, and sends the result in an encrypted
> premaster secret message.
>
> struct {
> ProtocolVersion client_version;
> opaque random[46];
> } PreMasterSecret;
>
> client_version The latest (newest) version supported by the
> client. This is used to detect version
> roll-back attacks.
> random 46 securely-generated random bytes.
>
It could be argued that the "latest (newest)" version is 3.01 i.e.
TLSv1. However MSIE uses 3.0 for client_version too and this chokes
OpenSSL's server code if TLSv1 is disabled because it is expecting the
client_version to match that in client_hello.
I recall various servers not tolerating s_client unless TLSv1 support is
turned off so maybe this should be changed. However if things are
changed its possible some SSLv3 servers also work like OpenSSL and they
will stop working :-(
A work around is to disable TLSv1 e.g. with -no_tls1 in s_client.
Steve.
--
Dr Stephen N. Henson. http://www.drh-consultancy.demon.co.uk/
Personal Email: [EMAIL PROTECTED]
Senior crypto engineer, Celo Communications: http://www.celocom.com/
Core developer of the OpenSSL project: http://www.openssl.org/
Business Email: [EMAIL PROTECTED] PGP key: via homepage.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
