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

[David Benjamin]

It's just that extension in our experience. Enforcing that servers don't
send extensions they aren't supposed to generally works fine and is good
for the ecosystem. But that particular extension needs a quirk.

I suspect there was some confusion because ec_point_format_list can be
server-sent in TLS 1.2 while elliptic_curves cannot. To be honest, I think
that was just a mistake in RFC 4492. TLS 1.2 has no way for the server to
tell the client what curves are acceptable for client certificates while
the converse is possible. (TLS 1.3 avoids this mess entirely with
SignatureScheme.)

I do not know how widespread this one is. It looks like we coincidentally
retained the quirk for this extension in BoringSSL when we first rewrote
our extension-handling from the 1.0.2 code. Later on, I encountered the
issue unrelatedly (I was probing some servers with some custom Go code),
noticed we were already tolerant of this, and merely added a clarifying
comment:
https://boringssl.googlesource.com/boringssl/+/4ac2dc4c0d48ca45da4f66c40e60d6b425fa94a3

(Speaking of which, I think I forgot to inform the vendor. I'll send them a
note.)

David

On Tue, Oct 3, 2017 at 11:16 AM Benjamin Kaduk via openssl-dev <
openssl-dev at openssl.org> 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.
>
> Thanks,
>
> Ben
> --
> openssl-dev mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20171003/c9ce4f67/attachment.html>