[tor-bugs] #26923 [Circumvention/Pluggable transport]: Intent to create Pluggable Transport: HTTPS proxy

Tor Bug Tracker & Wiki blackhole at torproject.org
Fri May 17 18:06:33 UTC 2019


#26923: Intent to create Pluggable Transport: HTTPS proxy
-----------------------------------------------+---------------------------
 Reporter:  sf                                 |          Owner:  (none)
     Type:  project                            |         Status:  new
 Priority:  Medium                             |      Milestone:
Component:  Circumvention/Pluggable transport  |        Version:
 Severity:  Normal                             |     Resolution:
 Keywords:  pt httpsproxy                      |  Actual Points:
Parent ID:                                     |         Points:  30
 Reviewer:                                     |        Sponsor:  Sponsor19
-----------------------------------------------+---------------------------
Changes (by phw):

 * cc: phw (added)
 * points:   => 30


Comment:

 Thanks a lot for filing this, sf! Has there been any further development
 since you posted the code on here?

 Here are some thoughts after I had a look at the code and design:

 * I just set up an httpsproxy bridge. It looks like the caddy dependency
 has an outdated dependency on `github.com/lucas-clemente/quic-go/h2quic`
 but the current version seems to expose `github.com/lucas-clemente/quic-
 go/http3`. After updating this in my local caddy clone, I got httpsproxy
 to work. There's also a dependency on `github.com/Jigsaw-
 Code/volunteer/server/inithack` but this repository doesn't seem to exist
 anymore.

 * I quite like the idea of naive proxies because it solves the problem of
 "we need to expose a bridge's OR port" (#7349) and already-deployed web
 servers host "natural" content that won't look suspicious to censors. All
 of this, however, comes at a cost: Getting httpsproxy bridges registered
 in BridgeDB will be tricky.  Bridges make it into BridgeDB by first
 sending their bridge descriptor to the bridge authority, which
 periodically copies all bridges it collected over to BridgeDB. The bridge
 authority doesn't know how to speak anything other than vanilla Tor to
 bridges. Naive proxies aren't bridges, and would thus have to make it into
 BridgeDB over a different channel. A snowflake-style broker may be a
 better solution here, so we don't have to deal with BridgeDB altogether,
 but we also have to have a bridge distribution strategy that makes it
 difficult to enumerate all httpsproxies.  Snowflake doesn't have to deal
 with this because its proxies are short-lived.

 * For bridge operators who set up an HTTP server just for the sake of
 running httpsproxy, I worry that the hosted content will be easy to
 attribute to httpsproxy. I don't think we can expect bridge operators to
 be creative and figure out what non-fingerprintable content to host, so we
 should have an automated solution to this.

 * The re-dialing approach to fix the connection lifetime fingerprint
 sounds fine. We should also randomise the times at which clients re-dial.
 It also makes me wonder how much of the web would break if a censor were
 to reset TCP connections to web servers after, say, 30 seconds.

 * Your "probe a web server without credentials" attack worries me too. I
 would expect web servers that support CONNECT to be very rare, to a point
 where a censor is willing to block them all, but my intuition may be off
 here. Also, with its active probing infrastructure, the GFW seems well-
 equipped to start such an attack whenever it pleases.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/26923#comment:6>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online


More information about the tor-bugs mailing list