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

[Matt Caswell]

On 03/10/17 16:15, Benjamin Kaduk via openssl-dev wrote:
> 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.

Looks like we should have an exception for this case (with a suitable
comment explaining why). Will you create a PR?

Matt