← Back to context

Comment by MBCook

8 hours ago

As someone hasn’t followed this, what was wrong with ESNI?

I was curious as well, https://blog.mozilla.org/security/2021/01/07/encrypted-clien... has some info

>analysis has shown that encrypting only the SNI extension provides incomplete protection. As just one example: during session resumption, the Pre-Shared Key extension could, legally, contain a cleartext copy of exactly the same server name that is encrypted by ESNI. The ESNI approach would require an encrypted variant of every extension with potential privacy implications, and even that exposes the set of extensions advertised. Lastly, real-world use of ESNI has exposed interoperability and deployment challenges that prevented it from being enabled at a wider scale.

China and Russia started to block ESNI before Cloudflare stopped offering it so any argument that ESNI did not work is dubious

IME, ESNI worked for accessing _all_ websites using CF. AFAIK, ECH has never been offered for all websites using CF

ESNI was a bit simpler to use than ECH, e.g., when making HTTP requests with programs like openssl s_client, bssl client, etc. (I don't use popular browsers to make HTTP requests)

When CF ended the ESNI trial, there was nothing to take its place. The public was asked to wait for ECH

It has been roughly five years (correct me if wrong) without any replacement solution for plaintext SNI

ECH is available on a few test sites, e.g.,

https://test.defo.ie

But software support for ECH makes little practical difference for www users if major CDNs still don't support it

And as far as a solution that applies to CDNs other than CF, there has been no solution at all

Plaintext SNI is everywhere. It more or less defeats the stated purpose of "encrypted DNS"

As far as I know, ESNI was pushed to a large number of websites in a very fast pace, and soon completely blocked by GFW. Then I didn't hear news about ESNI.