Ben Laurie wrote:
> Roland Mechler wrote:
> >
> > I posted this to openssl-dev and haven't got a response, so, I dunno, maybe this
> > list is more appropriate.
>
> It was in my queue!
I can't help it, I'm impatient. :-)
> > 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.
>
> It seems to me that you are right. However, it is far from clear to me
> that the code actually implements what the comment suggests it does. I'm
> still thinking about that!
Well, it appears that ssl3_get_client_hello(SSL *s) totally ignores the
client_version field in the ClientHello, so it continues using the version it
already is (i.e.,whatever version is set in s->version, be that SSL3_VERSION
or TLS1_VERSION). Assuming that's what's meant by "native type", I think
the comment correctly describes what the code does (by not doing anything).
The "This down switching should be handled by a different method." part of the
comment is rather nebulous though.
I think that the version negotiation should be based on what's in the ClientHello.
If ssl3_get_client_hello() is called via the SSLv23 method, then s->version and
s->method should be set to the version in the ClientHello (currently they are
set to the version of the containing record, in ssl23_get_client_hello(), before
it gets to this point). If either the SSLv3 or the TLSv1 method is being used
(i.e., set at the user level), and the version in the ClientHello doesn't match, then
the server should probably abort the handshake (although I'm not sure about
that).
Anyway, thanks for your response, and I look forward to hearing more thoughts
on this.
-Roland
S/MIME Cryptographic Signature
