On Fri, Nov 06, 2015 at 11:58:44PM +0000, Matt Caswell wrote:
> > On the server side, if at all possible, the selected protocol will
> > be the highest one not disabled.
>
> On the server side the selected protocol will *always* be the highest
> one not disabled.
True, at present. And yet this may not be the correct long-term
strategy. There may be future situations in which selecting the
highest protocol is not the right approach, and the right choice
might be to select the highest protocol that does not fail. There
was some discussion of this on the TLS WG list a moth or two back.
So I did not feel that we can guarantee the present behaviour in
perpetuity.
> > The client proposes a range from lowest to highest.
This is a correct description of the client-sider behaviour. IIRC
uses the lowest supported version at the record layer, and proposes
the highest in the HELLO message. In any case, the range of versions
of versions accepted by the client is always contiguous, and the
highest offerred will not be the highest supported when there are
"holes" created by disabling versions in the middle of the range
supported by the library.
> OpenSSL only considers the version provided by the client in the
> ClientHello itself.
That's server behaviour. The server will indeed only look at the
version in the client HELLO, and choose at most that, and if the
choice is too low, the client will object.
https://tools.ietf.org/html/rfc5246#appendix-E
Earlier versions of the TLS specification were not fully clear on
what the record layer version number (TLSPlaintext.version) should
contain when sending ClientHello (i.e., before it is known which
version of the protocol will be employed). Thus, TLS servers
compliant with this specification MUST accept any value {03,XX} as
the record layer version number for ClientHello.
TLS clients that wish to negotiate with older servers MAY send any
value {03,XX} as the record layer version number. Typical values
would be {03,00}, the lowest version number supported by the client,
and the value of ClientHello.client_version. No single value will
guarantee interoperability with all old servers, but this is a
complex topic beyond the scope of this document.
I don't recall what version OpenSSL clients use for initial handshakes
at the record layer, it is either 3.0 (fixed) or lowested supported
(the minimum I alluded to).
> In the above I used a hacked OpenSSL client to advertise TLSv1.2 in the
> ClientHello *and* to use TLSv1.2 in the record layer. OpenSSL server has
> had TLSv1.2 disabled so it selected TLSv1.1.
Right the server ignores the record layer version, which is what
RFC 5246 recommends, though IIRC "unhacked" OpenSSL does send the
minimum at the record layer.
> OpenSSL selects the version it is going to use regardless of the
> available ciphersuites. Only after selecting its version will the server
> select the ciphersuite to use. If there aren't any compatible with the
> selected version then it will fail with a "no shared cipher" error.
Will we always do that. I am not confident we can promise this,
but this is not at present about to change.
--
Viktor.
