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

[Tor Bug Tracker & Wiki]

#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:  httpsproxy, anti-censorship-         |  Actual Points:
  roadmap-september                              |
Parent ID:                                       |         Points:  30
 Reviewer:                                       |        Sponsor:
                                                 |  Sponsor28-can
-------------------------------------------------+-------------------------

Comment (by sf):

 Just noticed the response by phw.

 Development of this transport was put on hold after I didn't manage to
 convince Golang devs to add
 [[https://github.com/golang/go/issues/26900|padding support  at a user-
 accessible layer]] in x/net/http2. This seemed to be the easiest way to
 add padding, and since that didn't work out, we'd have to find another
 way.
 I think the way to go to is to use an additional inner layer, that will
 allow to send padding. PT client and server could communicate whether they
 support said layer in a HTTP header during the "HTTP CONNECT ->   <- HTTP
 OK" phase, and not lose interoperability with other clients and servers.

 Seems like I'll have to update Caddy dependencies. Hopefully the
 "inithack" isn't necessary anymore, but we'll see.

 I agree with your thoughts on BridgeDB, and that Snowflake's broker won't
 cut it due to not having sophisticated protection against enumeration. Not
 sure if it would be better to roll a new BridgeLiteDB or expand the
 regular one.


 > 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.

 I do share this concern, but this is something censor also would want to
 automate, and I doubt they will have an easy time doing that. Censor would
 have to learn how to crawl websites at scale and distinguish proxy-looking
 websites from legitimate ones. While it is suspicious to exchange GBs of
 traffic with a website that just looks like Apache2 default page, I feel
 like it take some time and effort for censors to catch up and implement
 blocking even for an effortless default like that, while we figure out
 better solutions.

  * A good idea might be to ask people to deploy websites with login forms,
 such that censor can't be too sure that there isn't more content on a
 given website.
  * When/if the encrypted SNI comes, we can just respond to probes with
 "Wrong SNI"! The added benefit is that, to my knowledge, the usual way to
 say "Wrong SNI!" is a vague handshake_failure alert, so censor may not
 even be sure if it's the SNI or if they're not offering right
 ciphers/curves/etc. We could employ that strategy before the encrypted SNI
 comes too, however, currently the censor is supposed to be able to use
 their network access to see which SNI people are using to connect to which
 IPs. This also defeats the "probe a web server without credentials"
 attack.
  * We can also do a reverse proxy to a randomly chosen website, if the
 client didn't demonstrate the knowledge of the secret (somewhere in
 ClientHello). This also defeats the "probe a web server without
 credentials" attack.
  * Automated website generation could be a useful direction, but I am not
 sure what that would look like. Simply fetching content from various
 randomly chosen places with some bits of randomized customization may be
 practical.

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