Re: [tor-dev] Domain Fronting, Meek, Cloudflare, and Encrypted SNI...
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
Re: [tor-dev] Domain Fronting, Meek, Cloudflare, and Encrypted SNI...
On Wed, 03 Oct 2018 19:01:21 +, David Fifield wrote: ... > And for that matter, why not a plain old HTTP CONNECT proxy? Because the typical load balancer/forwarder would have to decide whether to forward that CONNECT or do it itself, and some other. CONNECT with a Host: header - I'm not sure there is such a thing. > That would > be even more efficient. But we're limited to what the CDN supports. Most > CDNs only support basic methods like GET and POST, not CONNECT or the > special headers needed by WebSocket. Yes. No. 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. But websockets are a relevant thing unlike CONNECT, so I do expect all major players to implement that (and the components I know of (haproxy, nginx, apache, golang) are there already). - Andreas -- "Totally trivial. Famous last words." From: Linus Torvalds Date: Fri, 22 Jan 2010 07:29:21 -0800 ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Domain Fronting, Meek, Cloudflare, and Encrypted SNI...
On Wed, Oct 03, 2018 at 07:01:21PM -0600, David Fifield wrote: > And for that matter, why not a plain old HTTP CONNECT proxy? That would > be even more efficient. I should add that--leaving out domain fronting/encrypted SNI--there's an implementation of exactly this, a pluggable transport built on an HTTP proxy, by Sergey Frolov et al. He has been trying to get some attention or buy-in to get it integrated into Tor Browser, but hasn't had much luck so far. In my opinion, it will make a great alternative to obfs4 and be effective in many situations. There's a bit more to it than I've described above. It can work with any HTTP proxy (with HTTPS encryption to hide the destination from the censor, of course)--but they've also implemented a proxy plugin for the Caddy web server, which supports authentication. The authentication is to resist active probing like the GFW does: a genuine client who got the password through BridgeDB will be able to use the proxy, while a censor probing IP address will just get the web server's normal pages. Check the links for more info. https://bugs.torproject.org/26923 https://github.com/sergeyfrolov/httpsproxy ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Domain Fronting, Meek, Cloudflare, and Encrypted SNI...
On Mon, Oct 01, 2018 at 07:55:31PM +0200, Andreas Krey wrote: > On Mon, 24 Sep 2018 20:23:58 +, David Fifield wrote: > ... > > "encrypted SNI" part. But it's possible to do better: if you're willing > > to abandon HTTP/1.1 compatibility and require HTTP/2, you can use the > > "server push" feature to implement a serialization that's much more > > efficient than the current one in meek. > > How about websockets instead of trying to cram this into HTTP/2? And for that matter, why not a plain old HTTP CONNECT proxy? That would be even more efficient. But we're limited to what the CDN supports. Most CDNs only support basic methods like GET and POST, not CONNECT or the special headers needed by WebSocket. Cloudflare does support WebSocket, though: https://www.cloudflare.com/website-optimization/web-sockets/ https://blog.cloudflare.com/cloudflare-now-supports-websockets/ So this, combined with encrypted SNI, could be a viable technique when tunneling through Cloudflare--it just wouldn't be portable to other services. We even already have an existing WebSocket-based pluggable transport implementation--it would need changes to the client to support encrypted SNI. https://gitweb.torproject.org/pluggable-transports/websocket.git/ ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Domain Fronting, Meek, Cloudflare, and Encrypted SNI...
On Mon, 24 Sep 2018 11:57:48 +, David Fifield wrote: > I have to admit that I don't fully understand the apparent enthusiasm > for encrypted SNI from groups that formerly were not excited about > domain fronting. It's simply wrong to use different names in SNI and the host header. :-) > customer's domains are potentially affected, rather than just one. It's > a rational enough viewpoint (greater potential collateral damage ??? lower > probability of blocking), but to my mind encrypted SNI doesn't > fundamentally alter the nature of the game, it just raises the stakes. But in a game-changingly massive way. Remember the github blocking? When you block one domain that is on cloudflare, almost noboby will care. When you block all of cloudflare you will get an outcry of a lot of people, and probably worse for the censors, businesses. - Andreas -- "Totally trivial. Famous last words." From: Linus Torvalds Date: Fri, 22 Jan 2010 07:29:21 -0800 ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Domain Fronting, Meek, Cloudflare, and Encrypted SNI...
On Mon, 24 Sep 2018 20:23:58 +, David Fifield wrote: ... > "encrypted SNI" part. But it's possible to do better: if you're willing > to abandon HTTP/1.1 compatibility and require HTTP/2, you can use the > "server push" feature to implement a serialization that's much more > efficient than the current one in meek. How about websockets instead of trying to cram this into HTTP/2? - Andreas -- "Totally trivial. Famous last words." From: Linus Torvalds Date: Fri, 22 Jan 2010 07:29:21 -0800 ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Domain Fronting, Meek, Cloudflare, and Encrypted SNI...
On Mon, Sep 24, 2018 at 01:46:10PM -0400, Nathaniel Suchy wrote: > What this means: > Effectively domain fronting works by sending a different SNI and host header. > CDN providers like Cloudflare started double checking to make governments > happy, scratch that line, I mean to protect their customers from fraud and > abuse. They seem to of backtracked now. Encrypted SNI means that a firewall or > coffee shop owner won’t be able to use SNI to see the real origin of TLS > traffic. What we would need in order for meek to used encrypted SNI would be either: 1) support for encrypted SNI in Go's crypto/tls package; or 2) support for encrypted SNI in the Firefox that ships with Tor Browser, which meek-client could use through its TLS camouflage helper support. IMO (2) is less desirable because I'd like to get rid of the TLS camouflage helper support and replace it with a Go-level TLS camouflage library: https://github.com/refraction-networking/utls. The TLS helper works, but its complexity is a pain to deal with and leads to problems like https://bugs.torproject.org/12774 https://bugs.torproject.org/25405. Note, however, that a transport based on encrypted SNI doesn't have to be meek per se. I use "meek" to refer to a specific combination of domain fronting and a certain (fairly stupid and inefficient) HTTP/1.1 serialization of a bidirectional byte stream. It's conceptually straightforward to simply replace the "domain fronting" part with an "encrypted SNI" part. But it's possible to do better: if you're willing to abandon HTTP/1.1 compatibility and require HTTP/2, you can use the "server push" feature to implement a serialization that's much more efficient than the current one in meek. It may even be better to start over with a new codebase, it's not like meek's code is that large. But tjr's point stands: I think it's best not to push anything like this out until after encrypted SNI has seen some level of adoption by browsers. ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
