I posted this to openssl-dev and haven't got a response, so, I dunno, maybe this
list is more appropriate.
This is actually something I came across with SSLeay 0.9.0b, but the relevant
code for OpenSSL 0.9.1c appears to be the same. The server code, when using the
v23 method, uses the version in the record containing the ClientHello for
version negotiation rather than client_version in the ClientHello itself.
Specifically, if a 3.1 (TLS) record containing a 3.0 ClientHello is received,
the server sets 3.1 as its native protocol (and responds with 3.1 in the
ServerHello). This appears to be a clear violation of the TLS 1.0 spec, which
states:
7.4.1.3. Server hello
...
server_version
This field will contain the lower of that suggested by the
client in the client hello and the highest supported by the
server. ...
Nevertheless, it appears that this was done intentionally in SSLeay, as
suggested by this comment taken from ssl3_get_client_hello() in 3_srvr.c
(the context of which is not entirely clear to me):
/* We do this so that we will respond with our native type.
* If we are TLSv1 and we get SSLv3, we will respond with TLSv1,
* This down switching should be handled by a different method.
* If we are SSLv3, we will respond with SSLv3, even if prompted with
* TLSv1.
*/
Now it is perhaps not proper to put a 3.0 hello in a 3.1 record, as the spec
states that the version in the hello should be the highest supported by the
client. Nevertheless, it's not clear that that is a protocol violation, whereas
responding to 3.0 in the ClientHello with 3.1 in the ServerHello is.
Any comments on this issue will be greatly appreciated.
-Roland
S/MIME Cryptographic Signature
