I have an embedded device, using mBedTLS, trying to open a connection to https://www.cloudflare.com and is failing with:
#define MBEDTLS_ERR_PK_UNKNOWN_NAMED_CURVE -0x3A00 /**< Elliptic curve is unsupported (only NIST curves are supported). */
Due to hardware constraints, the device only supports the following curves:
MBEDTLS_ECP_DP_SECP192R1 MBEDTLS_ECP_DP_SECP224R1 MBEDTLS_ECP_DP_SECP256R1
And has the following TLS extensions enabled:
Supported Elliptic Curves Supported Point Formats
Looking at the cloudflare.com certificates: https://www.ssllabs.com/ssltest/analyze.html?d=www.cloudflare.com&s=184.108.40.206
I can see cloudflare.com supports both and RSA and ECDSA certificates.
The ECDSA server certificate uses a 256 bit EC key but the issuer of that cert uses a 384 bit EC key.
This is what is causing the device to fail. The device is not able to validate the 384 bit cert in the chain.
So, is this an issue with cloudflare.com? Should the server see that the client does not support all the curves in its certificate chain and revert to the RSA certs instead?
i.e. The device provides a list of curves it supports, yet the server returns a cert chain with a non-supported EC in the chain. Is the server expected to review the ‘Supported Elliptic Curves’ TLS extension provided by the client any only return the cert chain if all the curves are supported?
Any insight is appreciated.
Whenever you’re not sure how a protocol should behave, refer to its definition. For protocols in wide use on the Internet, this is usually one or more RFCs.
In this case, RFC 8422 is quite explicit about what must happen in this scenario: The server must not try to use an ECC certificate if the client does not support the elliptic curves used in that certificate.
Section 5.1 explains that the server must not try to negotiate ECC if the negotiation would fail:
A server that receives a ClientHello containing one or both of these
extensions MUST use the client’s enumerated capabilities to guide its
selection of an appropriate cipher suite. One of the proposed ECC
cipher suites must be negotiated only if the server can successfully
complete the handshake while using the curves and point formats
supported by the client (cf. Sections 5.3 and 5.4).
NOTE: A server participating in an ECDHE_ECDSA key exchange may use
different curves for the ECDSA or EdDSA key in its certificate and
for the ephemeral ECDH key in the ServerKeyExchange message. The
server MUST consider the extensions in both cases.
If a server does not understand the Supported Elliptic Curves
Extension, does not understand the Supported Point Formats Extension,
or is unable to complete the ECC handshake while restricting itself
to the enumerated curves and point formats, it MUST NOT negotiate the
use of an ECC cipher suite. Depending on what other cipher suites
are proposed by the client and supported by the server, this may
result in a fatal handshake failure alert due to the lack of common
Section 5.3 is equally explicit:
The server constructs an appropriate certificate chain and conveys it
to the client in the Certificate message. If the client has used a
Supported Elliptic Curves Extension, the public key in the server’s
certificate MUST respect the client’s choice of elliptic curves. A
server that cannot satisfy this requirement MUST NOT choose an ECC
cipher suite in its ServerHello message.) (emphasis mine)
Looks like you’re making a bug report to CloudFlare after all.
This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported License.