[openssl-users] Does openssl server always choose highest TLS version offered?

[Matt Caswell]

On 07/11/15 02:54, Viktor Dukhovni wrote:
> 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.

Agreed. I described current behaviour. Anything could change in the future.

> 
>>> 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.

There are 3 scenarios for the record layer version used by an OpenSSL
client in the initial ClientHello (at least this is the case for 1.0.2
and I believe it is also the case for 1.0.1 and 1.0.0. 0.9.8 is slightly
different):

- the lowest supported non-disabled version is SSL2 and there are SSL2
ciphers offered by the client, in which case an SSL2 compat ClientHello
is used and there is no record layer version.
- there are no SSL2 ciphers offered, SSLv3 is enabled and TLSv1.0 is
disabled in which case SSLv3.0 is used as the record layer version.
- in all other cases TLSv1.0 is used as the record layer version
regardless of which protocols are disabled.

Note that the last scenario means that TLS1.0 can be used as the initial
ClientHello record version even if TLS1.0 has been disabled.

You are correct about the contiguous range and "holes".


> 
>> 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.
> 

I think it is very unlikely to change for the currently available
released versions - and it is the behaviour of those versions that I am
describing. It could possibly change for future versions (as could
anything) - although I'm not aware of any plans to do so.


Matt