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