On 8/23/2022 8:58 PM, 涛叔 wrote:
Hi, Christopher,
On Aug 24, 2022, at 11:19, Christopher Patton<cpat...@cloudflare.com> wrote:
It's true that reverse proxies, like Cloudflare, terminate TLS for a large
number of names and therefore have the potential to provide a higher degree of
privacy. But I don't think it's fair to say that smaller TLS servers don't
benefit from ECH.
I never say the smaller TLS servers don't benefit from ECH. Every one does.
What I said is those standalone small VPS server, working in share mode, will
prepare to different domain for inter and outer SNI.
ECH can encrypt the ALPN and other parameters. The "QUIC Protected
Initials" proposal
(https://datatracker.ietf.org/doc/draft-duke-quic-protected-initial)
protects the initial QUIC handshake against interference by third
parties, and depends on ECH. So, even for an isolated server, ECH has value.
As there is no common proxy, all the domains are bounded to on site. This makes
protecting the inner domain useless, because
the outer one has a one-to-one responding to the inner one.
The current design works well for occasion using the intermediary proxy. But we
could make it one step further to support
the occasion without intermediary proxy.
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.
-- Christian Huitema
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
