August 2022 - tor-dev - lists.torproject.org

Two features that would help load-balanced bridges
by David Fifield 01 Jun '23

01 Jun '23

After the blocking of Tor in Russia in December 2022, the number of Snowflake users rapidly increased. Eventually the tor process became the limiting factor for performance, using all of one CPU core. In a thread on tor-relays, we worked out a design where we run multiple instances of tor on the same host, all with the same identity keys, in order to effectively use all the server's CPU resources. It's running on the live bridge now, and as a result the bridge's bandwidth use has roughly doubled. Design thread https://forum.torproject.net/t/tor-relays-how-to-reduce-tor-cpu-load-on-a-s… Installation instructions https://gitlab.torproject.org/tpo/anti-censorship/team/-/wikis/Survival-Gui… Two details came up that are awkward to deal with. We have workaround for them, but they could benefit from support from core tor. They are: 1. Provide a way to disable onion key rotation, or configure a custom onion key. 2. Provide a way to set a specific authentication cookie for ExtORPort SAFE_COOKIE authentication, or a new authentication type that doesn't require credentials that change whenever tor is restarted. I should mention that, apart from the load-balancing design we settled on, we have brainstormed some other options for scaling the Snowflake bridge or bridges. At this point, none of these ideas can immediately be put into practice, because there's no way to tell tor "connect to one of these bridges at random, but only one," or "connect to this bridge, but accept any of these fingerprints." https://bugs.torproject.org/tpo/anti-censorship/pluggable-transports/snowfl… # Disable onion key rotation Multiple tor instances with the same identity keys will work fine for the first 5 weeks (onion-key-rotation-days + onion-key-grace-period-days), but after that time the instances will have independently rotated their onion keys, and clients will have connection failures unless the load balancer happens to connect them to the instance whose descriptor they have cached. This post investigates what the failure looks like: https://lists.torproject.org/pipermail/tor-relays/2022-January/020238.html Examples of what could work here are a torrc option to set onion-key-rotation-days to a large value, an option to disable onion key rotation, an option to set a certain named file as the onion key. What we are doing now is a bit of a nasty hack: we create a directory named secret_onion_key.old, so that a failed replace_file causes an early exit from rotate_onion_key. https://gitweb.torproject.org/tor.git/tree/src/feature/relay/router.c?h=tor… There are a few apparently benign side effects, like tor trying to rebuild its descriptor every hour, but it's effective at stopping onion key rotation. https://lists.torproject.org/pipermail/tor-relays/2022-January/020277.html # Stable ExtORPort authentication ExtORPort (extended ORPort) is a protocol that lets a pluggable transport attach transport and client IP metadata to a connection, for metrics purposes. In order to connect to the ExtORPort, the pluggable transport needs to authenticate using a scheme like ControlPort authentication. https://gitweb.torproject.org/torspec.git/tree/proposals/217-ext-orport-aut… tor generates a secret auth cookie and stores it in a file. When the pluggable transport process is managed by tor, tor tells the pluggable transport where to find the file by setting the TOR_PT_AUTH_COOKIE_FILE environment variable. In the load-balanced configuration, the pluggable transport server (snowflake-server) is not run and managed by tor. It is an independent daemon, so it doesn't have access to TOR_PT_AUTH_COOKIE_FILE (which anyway would be a different path for every tor instance). The bigger problem is that tor regenerates the auth cookie and rewrites the file on every restart. All the tor instances have different cookies, and snowflake-server does not know which it will get through the load balancer, so it doesn't know what cookie to use. Examples of what would work here are an option to use a certain file as the auth cookie, an option to leave the auth cookie file alone if it already exists, or a new ExtORPort authentication type that can use the same credentials across multiple instances. What we're doing now is using a shim program, extor-static-cookie, which presents an ExtORPort interface with a static auth cookie for snowflake-server to authenticate with, then re-authenticates to the ExtORPort of its respective instance of tor, using that instance's auth cookie. https://lists.torproject.org/pipermail/tor-relays/2022-January/020183.html

2 2

GSoC 2022 - Tor Weather: Improving the Tor Network
by Sarthik Gupta 19 Sep '22

19 Sep '22

Hello everyone, I’m Sarthik Gupta (irc: sarthikg), a recent grad from Punjab Engineering College, Chandigarh & currently working as a Software Engineer at Soroco. This summer, I’ll be working on GSoC Project: “Tor Weather: Improving the Tor Network” with my mentors GeKo & Silvia. I’m extremely excited to be a part of Tor and am interested in working on this project! Briefing about the project: As of now, if any relay disappears from the tor-network, no one will know. This causes the network to lose out on bandwidth from nodes which have been down for hours because no-one knew they were down. Tor-Weather aims at solving this by creating a notification service which relay operators can subscribe to in order to get various types of updates for their relays. The tor-weather service will offer a plethora of notifications options for the relays. These include, the node being down, running on EOL/Outdated version, losing a flag, ranking in top 20/50/100, etc. These notifications can be subscribed & customised by the relay operators to fit their needs using a web-frontend. A detailed proposal for this project is available at: <https://gitlab.torproject.org/sarthikg/tor-weather/-/wikis/Proposal> https://gitlab.torproject.org/sarthikg/tor-weather/-/wikis/Proposal. I plan to keep this wiki updated with the progress & design decisions taken throughout the development of the project. Suggestions are always welcomed! Please reach out to us in irc (#tor-dev) for any ideas, questions, or suggestions you might have. Thanks, Sarthik Gupta

1 5

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

Counting HS descriptor uploads
by Michael Rogers 17 Aug '22

17 Aug '22

Hi, The Briar team is working on a new app that uses Tor hidden services, and we're trying to work out when the server publishing a hidden service should consider the service to be reachable by clients. We've tried counting HS descriptor uploads via control port events, but we found that when republishing a hidden service that has been published before, the number of descriptor uploads seems to vary. When republishing a hidden service, is it guaranteed that at least one copy of the descriptor will be uploaded? Or are there circumstances where Tor might decide that enough copies were previously uploaded, and still contain up-to-date information about introduction points etc, so no new copies need to be uploaded? Thanks, Michael

3 3

TOR socket for P2P in Python
by Martin Neuenhofen 16 Aug '22

16 Aug '22

Dear Tor Developers, in my application, a client connects to a server via: *client_socket = socket.socket(socket.AF_INET, socket.SOCK_STREAM)client_socket.connect(ip,port)* I want to replace these two lines to create a client_socket whose IP address cannot be seen by the server. The application is e-polling. I looked into - torpy (too many timeouts), - socks (requires too much external configuration), - and I have tor installed (unknown how to use from within python). I just need a replacement for the two-liner code above. *The ideal solution:* is device & OS agnostic, portable, uses no peripherals or configuration (i.e., just one pip package to install), and works reliably. Thus, the below torpy solution would have been ideal if it had worked reliably: *from torpy import TorClient # pip install torpy* *class Torsocket:* * def __init__(self,ip,port): self.mgr1 = TorClient() self.tor = type(self.mgr1).__enter__(self.mgr1) self.mgr2 = self.tor.create_circuit(3) self.circuit = type(self.mgr2).__enter__(self.mgr2) self.mgr3 = self.circuit.create_stream((ip,port)) self.socket = type(self.mgr3).__enter__(self.mgr3) def send(self,data): self.socket.send(data) def recv(self,size): return self.socket.recv(size) def __del__(self): for bla in [self.mgr3,self.mgr2,self.mgr1]: type(bla).__exit__(bla, None, None, None)* It replaces the two-liner from the beginning with the below one-liner *client_socket = Torsocket(*server_data.server_address)* My questions/requests: - Is torpy connected to the real tor network (or is it a little toy twin)? If it is the real tor network then I will close this issue and open another one. - Are practical solutions available to my problem already?, and which of them works best for user-friendliness? - Can a pip package for a torsocket be made, as described above? i.e., something like torpy, but connecting to the real network? - Can I offer anything so that the ideal solution would be crafted and packaged?* *) If it helps, I could tell a lot about my project and how I believe it is significant and will be for the greater good of people. It is a fully implemented 1000LOC LSAG+WOT decentral P2P e-polling program with GUI that shall return trust and sovereignty into the people's hands. The only missing bit is a reliable tor connection.

2 3

bridge:// URI and QR codes
by meskio 10 Aug '22

10 Aug '22

Hello, We have a messy situation to share bridges between devices. BridgeDB and Tor Browser have QR codes but they use different format for them. There has being some attempts to standarize a bridge URI[0][1], but it looks like we never finished that work. Pier has produced an RFC of a bridge URI proposal: https://gitlab.torproject.org/tpo/applications/team/-/wikis/Design-Document… If you have an application that uses (or plan to use) bridge URIs or QR codes I'm interested on your take on that proposal. Do your application already have any kind of support for bridge URIs or QR codes? If so how do they look like? Will it break things if we change them? What do you think of the proposal? How can we improve it? Thank you. [0] https://gitlab.torproject.org/legacy/trac/-/issues/15035 [1] https://gitlab.torproject.org/tpo/applications/fenix/-/issues/40189 -- meskio | https://meskio.net/ -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- My contact info: https://meskio.net/crypto.txt -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Nos vamos a Croatan.

5 8