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@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
>
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
