[openssl-dev] rejecting elliptic_curves/supported_groups in ServerHello (new behavior in master/1.1.1 vs 1.1.0)

[Benjamin Kaduk]

Hi all,

Doing some testing with a snapshot of master (s_client with -tls1_2 and
optionally a cipherspec that prefers ECDHE ciphers), we're running into
a sizeable number of servers that are sending extension 0xa (formerly
"elliptic_curves", now "supported_groups") in the ServerHello.  This is
not supported by RFC 7919 or RFC 4492 (the server is supposed to
indicate it's selected curve/group in the ServerKeyExchange message
instead), or by the TLS 1.3 draft spec (which permits "supported_groups"
in EncryptedExtensions, so the client can update a cache of groups
supported by the server).

In OpenSSL 1.1.0 we seem to have treated the elliptic_curves extension
in a ServerHello as an extension unknown to the library code and passed
it off to the custom extension handler.  With the extension processing
rework in master done to support TLS 1.3, which admits extensions in
many more contexts than previously, we now check that a received
extension is allowable in the context at hand.  In the table of
extensions, supported_groups is marked only as allowable in the
ClientHello and TLS 1.3 EncryptedExtensions, per the spec.  However,
this new strict behavior causes connection failures when talking to
these buggy servers.  So far we've seen this behavior from servers that
send a Server: header indicating Microsoft-IIS/7.5 and just "Apache".

This raises some question of what behavioral compatibility is desired
between 1.1.0 and 1.1.1 -- do we need to disable the "extension context"
verification for ServerHello processing entirely, or maybe just for the
one extension known to cause trouble in practice?  Or should we have an
SSL/SSL_CTX option to control the behavior (and which behavior should be
the default)?

Also, I'd be interested in hearing whether anyone else has observed this
sort of behavior.

Thanks,

Ben