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. _______________________________________________ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev