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

[Mahesh Bhoothapuri]

    if (SSL_CTX_set1_groups_list(ctx, "P-521:P-384:P-256") == 0) {
           //error
    }

    The client and server both use SSL_CTX_set1_groups-list to set the
supported group list.  Right now,  the server always
    has P-256 in the supported groups extension.
    When the the groups list is changed to add X25519,  the server responds
with P-256.   Is there a way to have the server support
    multiple specified groups.

    Section 9.1 of the rfc states:
    "

A TLS-compliant application MUST support digital signatures with
   rsa_pkcs1_sha256 (for certificates), rsa_pss_sha256 (for
   CertificateVerify and certificates), and ecdsa_secp256r1_sha256.  A
   TLS-compliant application MUST support key exchange with secp256r1
   (NIST P-256) and SHOULD support key exchange with X25519 [RFC7748
<https://tools.ietf.org/html/rfc7748>].
  "

  So, having the server support P-256 satisfies the MUST part.  How
can we support X25519 on the server, or

  a list of different groups.

Thanks,
Mahesh

On Tue, Oct 3, 2017 at 8:15 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/20171004/51ace953/attachment-0001.html>