3

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=104.17.210.9

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.

6
  • I suspect the first thing you should do is to open a feature request with mbed TLS. Jun 7, 2019 at 18:29
  • @MichaelHampton A feature request to do what? I am asking if this is a server misconfiguration. The device provides a list of curves it supports via the 'Supported Curves TLS extension' yet the server returns a cert chain using curves not in the list.
    – driedler
    Jun 7, 2019 at 18:49
  • Then a bug report? I'm not sure why you brought this question to us at all, as it looks like you need to file either a bug report or feature request with the library developers. Jun 7, 2019 at 18:51
  • @MichaelHampton This has little to do with mBedTLS. I am asking if the issue is server-side on cloudflare.com. Why is the cloudflare.com server returning a cert chain containing an EC not supported by the device. Why doesn't the server use 'Supported Curves TLS extension' provided by the device and see that the 384 EC is not supported.
    – driedler
    Jun 7, 2019 at 19:00
  • That's a great question, but it's one you should direct to CloudFlare. This is a community site and nobody here is going to know the answer. CloudFlare's web server is extremely customized and there is none other like it on the planet. It's possible that they are the ones with whom you need to file the bug report. Jun 7, 2019 at 19:05

2 Answers 2

5

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 cipher suites.

Section 5.3 also says:

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.

Looks like you're making a bug report to CloudFlare after all.

2
  • 1
    I'm not sure whether that's a bug or a limitation of the Web PKI model. As it stands the server cannot know which CAs the client trusts and from the server's point of view, the certificate it's presenting is fully compliant with the requested constraints. The certificate chain on the other hand doesn't but the client might have the cloudflare.com leaf certificate in its trust store and the TLS connection could then be established despite the CA not honoring the expected constraints. Jun 10, 2019 at 22:10
  • @Ginnungagap Congrats, you've found a hole in the RFC. Given that the intention of the RFC is that the client's ability to handle specific elliptic curves and points should control whether ECC is used, the server should apply this check to its own certificate and to the certificate chain which signed it. Hopefully this oversight will be addressed in a future version of the RFC. Jun 11, 2019 at 17:15
0

It could well be a bug in mBedTLS that makes it advertise features / algorithms that it doesn't actually support in the as-built configuration. And that confuses the server.

Make a small standalone example program that demonstrates this behavior and report it to mBedTLS developers. Either they will tell you that it's a bug with CloudFlare or they will fix the bug in their library.

Because CloudFlare serves millions of users every day a broken configuration would show up very quickly. On the other hand mBedTLS is a very specific-use library that gets nowhere near the same amount of scrutiny. If I could I would bet on mBedTLS being wrong here, not CloudFlare.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .