Hi, Christian,
> On Aug 24, 2022, at 14:23, Christian Huitema <huit...@huitema.net> wrote:
>
> Yes, the server might tell its clients to use a fake external SNI, and that
> might fool some of the current censorship services. But that will only work
> until the next update to these services. If there is no proxy, then the IP
> address points directly to the isolated server. A lookup of the IP address in
> the DNS would provide the name of that server. Even if the server does not
> registers its address in the "in-addr.arpa", we have to assume that the
> censors run some kind of web spider and memorize the IP addresses of the
> servers that they want to censor.
>
> If you want to deploy servers that evade censorship, they cannot be isolated.
> They have to join some kid of pool, and the pool has to be big enough and
> important enough that censors cannot just block the IP address shared by all
> pool members. And then ECH will work as expected.
>
You are right. But it seems there is no such a pool.
Google is very common across the world. However, it is totally unreachable
across the China mainland.
If there are too many sites protected by some common pool like Cloudflare, this
pool will blocked absolutely.
When the Cloudflare deployed the ESNI initially, some website use Cloudflare to
accelerate speed can be accessed in China. And then, all request with
the ESNI extension has been blocked.
If we can deploy the ECH without the public_name, all website, whether join a
pool or not, could deploy ECH. And the censors cannot
easily block one site by its name. What the censors can only do is fetching the
A/AAAA record periodically and block that IP addresses.
And the server can easy change to the new IP addresses. This will not prevent
the censors from blocking, but makes it impossible to totally bock a website.
I think we need to try to make the Internet more decentralized.
And recall why the outer public_name is required? It is used to "correct" the
browsers' outdated ECHConfig. This feature can be accomplished by several
different ways, including DNSSEC or public some signing key by DNS. So why we
insist to use the outer TLS handshake?
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
