[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-bugs] #26923 [Circumvention/Pluggable transport]: Intent to create Pluggable Transport: HTTPS proxy
#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
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs