Feature Request: Detect EncryptedClientHello Support

[prajaybasu]

I am not sure if this is quite in the scope of sslscan but it would be nice to be able to verify ECH and ESNI in sslscan.

Verifying full support would require the appropriate DNS records to be present alongside the TLS extensions working as expected.

https://www.cloudflare.com/learning/ssl/what-is-encrypted-sni/
https://www.iana.org/assignments/tls-extensiontype-values/tls-extensiontype-values.xhtml
https://github.com/openssl/openssl/tree/feature/ech

[jtesta]

I think testing for the server's ability to accept EncryptedClientHello messages would be good to add, provided it can be done with a reasonable amount of C code. Does anyone know of any public endpoints that are available for testing? Or know of an easy way to set up an endpoint in a lab environment? Getting a test environment would be the first step to writing an implmentation.

[rbsec]

Once OpenSSL merged ECH into the master branch of an LTS version then supporting it would probably be a lot easier. Trying to write our own proper implementation sounds like a lot of extra complexity; although checking for support of the extension by crafting a ClientHelloOuter might be enough to give some indication?

As for ESNI, my understanding that it was deprecated a few years back and not widely deployed other than Cloudflare - so probably limited value in trying to support it?

[jtesta]

although checking for support of the extension by crafting a ClientHelloOuter might be enough to give some indication?

Yeah, maybe. That's why having a test endpoint would be very convenient for tinkering...

As for ESNI

From what I understand, the ESNI spec got fully replaced with ECH because the designers realized that only encrypting the SNI had too many shortcomings; encrypting the entire ClientHello would be the only strategy that adequately meets their original goals. You can see that draft 6 was called "Encrypted Server Name Indication for TLS 1.3" (https://datatracker.ietf.org/doc/draft-ietf-tls-esni/06/), but then the next draft in June 2020 its name was changed to "TLS Encrypted Client Hello".

Hopefully, this spec gets finalized soon. The process officially started in July 2018, and now they're on their 24th revision!

[prajaybasu]

Once OpenSSL merged ECH into the master branch of an LTS version then supporting it would probably be a lot easier.

I agree, I saw a few comments stating that ECH was supposed to land with OpenSSL 3.5 but doesn't seem like that worked out as planned. No point in supporting until OpenSSL does so this is mostly for tracking until then I suppose.

As for test sites, just about every Cloudflare endpoint supports it and you can test if sni=encrypted is returned by adding cgn-cgi/trace to the URL, e.g., prajaybasu.com/cdn-cgi/trace. Chromium browsers only enable it if they detect DNS over HTTPS or DNS over TLS being used so using a local DNS server break ECH on browsers unfortunately.

On a related note, QUIC is a little bit more common now due to HTTP/3, so it would be nice to be able to use sslscan over QUIC too but I wouldn't expect the configuration to be any different between TCP and UDP/QUIC very much . I have seen some HTTP/2 only endpoints for GraphQL so HTTP/3 only might not be completely out of question for some RPC services a few years down the line. Probably just a nice to have.