[tor-dev] Domain Fronting, Meek, Cloudflare, and Encrypted SNI...

[David Fifield]

On Thu, Oct 04, 2018 at 09:37:18AM +0200, Andreas Krey wrote:
> A quick search indicates that aws and azure are already
> supporting it, although I'm unable to interpret whether that is
> actually the respective product you are/were using.

That's exactly it. Of course you can spin up a random EC2 machine or
Azure VM and connect to it with WebSocket. But a random AWS or Azure IP
address doesn't have the properties we want--it is easily blockable.
Why? Because there are no other valuable services running on the same IP
address, once it is discovered, the censor can block it with virtually
zero cost. (Not that it's an unworkable model--that's basically how
obfs4 works--it means you have to have to be careful about distributing
bridges, and keep replenishing the pool as they are inevitably blocked.)
Encrypted SNI does not help you here, not when there is only one service
running on the IP address.

We specifically use the CDN service, because the high degree of
co-hosting behind a CDN edge server makes it more expensive to block. In
this case, encrypted SNI (or formerly domain fronting) really does help,
because there are many and valuable sites hosted there, and connections
to different sites look the same from the censor's point of view. We're
not connecting via a cloud service just for fun, but because we depend
critically on that co-hosting to make blocking difficult. It's possible
that services other than the CDN services also have that property--it
would require some investigation to uncover--but then you would have to
ensure that the other service, too, supports WebSocket.

I'm not saying a WebSocket-in-TLS transport is a bad idea. It's just
that there's more to it than the protocol you use. You also have to go
through a proxy server that's expensive to block. As a proxy server,
most CDNs will support an HTTP/2 tunnel, but not WebSocket. And if you
don't have a CDN in the middle, you may as well use a plain CONNECT
proxy rather than WebSocket.

Related reading:
https://tools.ietf.org/html/draft-ietf-tls-sni-encryption-03#section-2.2
	Many deployments still allocate different IP addresses to
	different services, so that different services can be identified
	by their IP addresses. However, content distribution networks
	(CDN) commonly serve a large number of services through a small
	number of addresses.
https://tools.ietf.org/html/draft-ietf-tls-esni-01#section-3.1
	In principle, the provider might not be the origin for any
	domains, but as a practical matter, it is probably the origin
	for a large set of innocuous domains, but is also providing
	protection for some private domains.