[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: 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
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs