1

Does a TLS client needs to support one of the named groups (curves?) supported by the server for TLS handshake to succeed?

Longer version:

I'm running a web site using Windows Server 2016. The web site has thousands of users and provides a REST API which many users interact with from various environments. Some of them are running older software like Windows XP and what not.

To make the web site more secure, I'm placing a web application firewall (WAF) in front of it to detect various attacks (like SQL injection and similar).

Historically when changing TLS configuration on the server, I've had various issues with clients who can no longer connect, for example due to mismatch in cipher support, old TLS/SSL-versions and the certificate chain not beeing fully included in the server response.

I've used Qualys SSL labs to compare the TLS configuration in the WAF with that of the old Windows Server 2016. The only thing which differs is that the old server supports a curve named "x25519" while the WAF does not. The old server also supports secp256r1, secp384r1 which is supported by the WAF.

The WAF instead support secp256r1, secp521r1, brainpoolP512r1, brainpoolP384r1, secp384r1, brainpoolP256r1, secp256k1, sect571r1, sect571k1, sect409k1, sect409r1, sect283k1, sect283r1.

What I'm trying to understand is whether I risk breaking backwards compatibility with clients if I remove the support for x25519.

Improve this question
2
  • WinXP schannel doesn't support ECC at all, so curve mismatch is meaningless. It also supports DHE only with 'DSS' (DSA) which in practice makes it nearly unusable (thus no forward secrecy) and doesn't support TLS versions above 1.0 (now commonly required) or data ciphers better than 3DES (no AES or ChaCha). Before/without SP3 it doesn't support SHA-2 signed certificates, which are effectively mandatory on the public net since 2015. But if software on XP uses its own stack, like OpenSSL, NSS, or Java, schannel doesn't matter.
    – dave_thompson_085
    Nov 21, 2019 at 6:26
  • If you have time and permission, you might want to put a network capture for a day or two and look at the ClientHello's you receive to see what your clients do and do not support.
    – dave_thompson_085
    Nov 21, 2019 at 6:28

1 Answer 1

Reset to default
1

For elliptical curve (EC) protocol, all that is needed is for the client and the server to support at least one common curve. However, if the client and the server do not support at least one common curve, they can try to agree on other protocols (such as DH).

But, in your case, it looks like the WAF supports a fairly large number of curves. Even though x25519 is not one of them, there are plenty of others supported by the WAF, many of which that are older than x25519, so I don't suspect you'll have too many clients that are unable to connect just because you no longer support x25519.

Improve this answer
2
  • Thanks. I appreciate your feedback. I know I'm taking a slight compatibility risk in this, but I do appreciate your view on it.
    – Nitradamus
    Nov 20, 2019 at 13:37
  • Most of that eclectic list of curves is older, but in practice for TLS almost nobody ever used any 'binary' (char-2) curve, or the Brainpool curves. The only popular curves -- and the only ones retained in TLS1.3 -- are the NIST-adopted prime curves P-256/secp256r1 P-384/secp384r1 P-521/secp521r1 and the Bernstein curves mostly x25519 and to a lesser extent x448.
    – dave_thompson_085
    Nov 21, 2019 at 6:32

You must log in to answer this question.

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