David Taylor <[EMAIL PROTECTED]> to [EMAIL PROTECTED]:
[...]
> We have added TLS 1.0 support but it is still in testing.
>
> A question about the TLS protocol. The specification states the client key
> exchange message should send the same version number that was included in
> the client hello - the highest supported. Testing against OpenSSL we didn't
> have any luck with this - if we tell OpenSSL to talk SSL (3.0) but still
> send 3.1 as the version in our client key exchange message (because that's
> what we sent in the client hello) we get an alert. The OpenSSL source has a
> comment to the effect this is a known bug but we'd like to make sure we're
> doing the right thing.
I cannot find such a comment in the OpenSSL source code, but it
certainly is a bug w.r.t. handling RSA-encrypted client key exchange
messages. (For your test case it's the SSL 3.0 specification that
counts, but it say essentially the same as the TLS spec: "The latest
(newest) version supported by the client. This is used to detect
version roll-back attacks." The TLS specification adds "Upon
receiving the premaster secret, the server should check that this
value matches the value transmitted by the client in the client hello
message.")
There's a commented-out line in OpenSSL's ssl/s3_srvr.c that should
provide correct behaviour for SSL-3.0-only mode ("s->client_version=..."
-- there's a comment preceding it which is actually wrong and which
existed in SSLeay before that inactive line of code was added,
this part of that bugfix was never activated).
The generic server (in ssl/s23_srvr.c), which can also handle
SSLv2-compatible client hellos and thus is the most important one in
real life, does set s->client_version according to the client's
message and thus avoids that problem (although it's so
incomprehensibly written that one cannot really be sure ...). However
it has another bug (reported earlier) in that for client hellos in the
SSL 3.0/TLS 1.0 format it remembers the version number from the record
header and not the one from the actual client hello message; and TLS
clients that talk to servers that may only speak SSL 3.0 should send
SSL 3.0-client hellos with version TLS 1.0 inside the client hello
message according to the TLS specification (which means that your test
situation cannot really be expected to work as you send a pure TLS 1.0
client hello to an SSL 3.0 server, unless you set the record version
number to 3.0 as requested by the specification, in which case you
could not interoperate with OpenSSL at all :-( ).
It looks to me that uncommenting that line s->client_version=...
in ssl/s3_srvr.c should solve both problems at once -- but certainly
extensive compatibility tests are needed to see if this does not cause
any new problems (I've not even compiled the changed version yet).
Also various comments on these issues are needed, and some obsolete
ones ought to be deleted.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
