August 2022 - anti-censorship-team - lists.torproject.org

Mac app / Safari extension for Snowflake
by David Fifield 02 Oct '25

02 Oct '25

Browsing through some search results, I found: https://apps.apple.com/us/app/torproject-snowflake/id1597501940 (https://web.archive.org/web/20220222083316/https://apps.apple.com/us/app/to…) https://github.com/jayluxferro/snowflake It looks like a repackaging of the Snowflake JavaScript proxy code for Mac and Safari environments. Maybe we could get in touch with the developer and find a way to adopt it into the main repository?

3 2

Microsoft announces shutting down domain fronting attempts in Azure
by Cecylia Bocovich 17 Nov '24

17 Nov '24

It looks like Azure is going to shutdown domain fronting: https://www.microsoft.com/security/blog/2021/03/26/securing-our-approach-to… There isn't a time frame listed in the article, and I haven't gotten any notifications through my Azure account yet. Cecylia

7 9

TorCloak Pluggable Transport
by Francisco Silva 06 Sep '22

06 Sep '22

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/

6 6

Introducing a Conjure PT for Tor
by Cecylia Bocovich 31 Aug '22

31 Aug '22

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

1 0