From de9919f38a0504d3eba66da35aa9d93c49f34e4a Mon Sep 17 00:00:00 2001 From: Daniel Stenberg Date: Thu, 6 Aug 2026 11:05:01 +0200 Subject: [PATCH] TODO: ECH for QUIC And drop: - Consider OCSP stapling by default It is a practice that is going out-of-style, so doing this by default now seems wrong. - Provide callback for cert verification We have lots of options already. Let's not do this. Closes #22504 --- docs/TODO.md | 18 ++++-------------- 1 file changed, 4 insertions(+), 14 deletions(-) diff --git a/docs/TODO.md b/docs/TODO.md index 0c65089b26..6203056994 100644 --- a/docs/TODO.md +++ b/docs/TODO.md @@ -479,20 +479,6 @@ By changing the order of TLS extensions provided in the TLS handshake, it is sometimes possible to circumvent TLS fingerprinting by servers. The TLS extension order is of course not the only way to fingerprint a client. -## Consider OCSP stapling by default - -Treat a negative response a reason for aborting the connection. Since OCSP -stapling is presumed to get used much less in the future when Let's Encrypt -drops the OCSP support, the benefit of this might however be limited. - -[curl issue 15483](https://github.com/curl/curl/issues/15483) - -## Provide callback for cert verification - -OpenSSL supports a callback for customized verification of the peer -certificate, but this does not seem to be exposed in the libcurl APIs. Could -it be? There is so much that could be done if it were. - ## Less memory massaging with Schannel The Schannel backend does a lot of custom memory management we would rather @@ -572,6 +558,10 @@ The feature matrix at https://curl.se/libcurl/c/tls-options.html shows which features are supported by which TLS backends, and thus also where there are feature gaps. +## ECH for QUIC + +curl's support for ECH is currently limited to TCP only. + # Proxy ## Retry SOCKS handshake on address type not supported