On Wed, Aug 24, 2022 at 12:06 AM 涛叔 <h...@taoshu.in> wrote: > 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. >
As a practical matter, most sites need to be deployed on cloud services like AWS, Cloudflare, etc., so if this is true, then ECH just isn't going to work at all. But, I don't think it's in fact going to be the case in many jurisdictions. 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. > Sites can do this right now by simply using a common invalid public_name, e.g., "esni.invalid" > And the server can easy change to the new IP addresses. > Why do you believe this to be the case? It's not clear to me that this is so. 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? > It's not clear to me what you have in mind here, so I can't tell whether these are real alternatives The setting in which the outer public_name is useful is the one in which the ECHConfig key is wrong but the ECHConfig public_name is correct, presumably, as you say, because DNS is out of date. How do you think DNSSEC fixes this problem? -Ekr
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
