Good evening,
My name is Francisco Silva and, together with Professor Nuno Santos and
Professor Diogo Barradas, am part of a research team [1] within the
Distributed Systems Group at INESC-ID Lisbon [2]/IST [3]. Our research
focuses on _systems security and privacy._
We are currently developing a new Tor Pluggable Transport called
TorCloak. TorCloak's basic mechanism is to conceale Tor traffic on the
video streams of WebRTC-based video conferencing services.
We are now coming to a stage on our project in which we are discussing
solutions to disseminate our bridges. In the attached file we present a
small draft of our proposed solution. This solution is geared towards
leveraging the bridge distribution infrastructure already made available
by the Tor project and make the process of establishing a bridge
connection as simple as possible for the user.
We would appreciate your feedback on this solution and, if possible,
work with us through the limitations and technicalities of such
implementation.
Please let us know if you have any questions. You can reach us via email
or Matrix. Looking forward to working with you.
--
Best regards,
Francisco Silva
franciscoasilva(a)tecnico.ulisboa.pt
@fsilva800:matrix.org
web.tecnico.ulisboa.pt/franciscoasilva
Links:
------
[1] https://syssec.gsd.inesc-id.pt/
[2] https://inesc-id.pt/
[3] https://tecnico.ulisboa.pt/en/
Conjure[0] is an anti-censorship tool in the refraction networking
(a.k.a. decoy routing) lineage of circumvention systems. The key
innovation of Conjure is to turn the unused IP address space of
deploying ISPs into a large pool of "phantom" proxies that users appear
to connect to. Due to the size of unused IPv6 address space and the
potential for collateral damage against real websites hosted by the
deploying ISPs, Conjure provides a possible solution to the problem of
censors enumerating and blocking deployed bridges or proxies.
I've been working with Jack Wampler and Eric Wustrow at the University
of Colorado to implement a Conjure PT for Tor that uses the existing
deployed Conjure stations[1].
# How it works
Conjure clients first perform a registration step with the Conjure
station to negotiate a phantom IP address to connect through. The idea
of a registration phase that precedes the proxied connection is common
among anti-censorship tools, including Snowflake. Like Snowflake, there
are a few options for making the registration process
censorship-resistant. Conjure currently offers unidirectional
registration via Tapdance[2] decoy routing, and bidirectional
registration via domain fronting.
Once the client and station have negotiated a phantom IP address, the
client makes a connection to the phantom address. The Conjure station
sees this connection and instead proxies traffic using the haproxy[3]
protocol to a client-specified destination. Conjure currently supports 3
different transport options for the connection between the client and
the phantom proxy: a minimal SSH-based transport, obfs4, and webrtc.
The Tor conjure pluggable transport[4] uses the gotapdance library[5] to
register and connect to the production Conjure station through the
negotiated phantom IP address. We have a deployed Tor bridge (named
Haunt) that accepts haproxy connections from an allowlist of known
Conjure stations. You can see details and usage metrics on Relay Search:
https://metrics.torproject.org/rs.html#details/A84C946BF4E14E63A3C92E140532…
# Next steps
This PT is currently in development and only recommended for testing.
We still have some work to do before the Tor Conjure PT can be rolled
out to a large user base. The PT in its current form is very minimal in
its features. We're reaching out to the development community now for
initial feedback and testing. We are planning a slow ramp of client
traffic to avoid placing stress on the stations and improve the
reliability and censorship resistance of our setup. Immediate planned
work includes:
- securing the haproxy connection between the Conjure station and the bridge
- making the registration connection censorship resistant
- ongoing testing and development of the obfs4 transport integration
- usability improvements and resilience in the event of overloaded
Conjure stations
- reproducible builds for Tor Browser
For more details, check out the issue tracker for this project[6].
We have a milestone for shipping conjure support in alpha version of Tor
Browser[7], which is the next major step in the rollout process.
# Try it out yourself
Instructions for cloning and building this PT are in the repository[4].
In the client/ directory there are two provided torrc files. For testing
the production Conjure deployment, you may use the one named `torrc`.
The other file, `torrc-testing` is for use with the libvirt-based
testing and development environment[8].
Successful bootstrapping can take a few tries due to high load at the
station. More detailed log messages will be written out to a log file
conjure.log by default. This can be changed by modifying the -log
argument in the ClientTransportPlugin line of the torrc file. If the
station is overloaded, you will see a message like the following in
conjure.log:
```
[11:32:12] [1-d9b572] failed to dial phantom [scrubbed]: dial tcp
[scrubbed]: i/o timeout
```
Please try it out, open issues, ask questions, provide feedback!
# Thanks!
Thanks again to Jack and Eric for their efforts on this project, and to
whole team of Conjure researchers, developers, and admins for their work
on deploying Conjure and making it available for use.
[0] https://censorbib.nymity.ch/pdf/Frolov2019b.pdf
[1] https://censorbib.nymity.ch/pdf/Frolov2017a.pdf
[2] https://censorbib.nymity.ch/pdf/Wustrow2014a.pdf
[3] https://www.haproxy.org/download/1.8/doc/proxy-protocol.txt
[4]
https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/conj…
[5] https://github.com/refraction-networking/gotapdance
[6]
https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/conj…
[7]
https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/conj…
[8] https://gitlab.torproject.org/cohosh/phantombox