Blocking-resistant communication through domain fronting (2015) [pdf]

icir.org

40 points·hartem_··8 comments

Here's the HTML version of PDF, video presentatiom, PDF of presentation:

https://news.ycombinator.com/item?id=13232756

Is it assumed that blacklisting IP's is a difficult challenge for a censor? Most major blacklisted sites have static or rarely changing addresses. Still, it's an interesting idea for small back channels.

It assumes that blacklisting a major domain (such as google.com) would be too expensive in terms of collateral damage.

Anyone know why so many web servers choose to internally reroute to different hosts?

Couldn't they just send a redirect, forcing the client to make a second request which would get blocked?

Various reasons. Here's a technical one: a redirect gets you one more HTTP roundtrip (and perhaps one more TCP roundtrip, and/or one more HTTPS handshake, and/or one more DNS lookup). In other words: this is simple on server-side but slooooooow and brittle on client-side.

As for the scenario "couldn't the censor send a redirect?" - no. Unless the user trusts the censor's CA (Etilasat or eDellRoot comes to mind), the censor doesn't see inside the HTTPS tunnel, only that it exists to an IP address (looked up by a previous DNS request).

(2015)

I wonder if this is even possible with HTTP2?

Can't see any reason it wouldn't work with HTTP2. And HTTP1.1 will still be supported for a long time anyway.

The real question is...How can I watch all of netflix?

Reply on news.ycombinator.com