February 2023 - 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

[CRITICAL] Deep Fingerprinting Traffic Correlation
by silentguard＠dnmx.org 28 Feb '23

28 Feb '23

Hi, I was the one who raised the issue of DeepCorr being able to perform traffic correlation with a high degree of accuracy but it seems like that WTF-PAD which is currently implemented in Tor does defend against the DeepCprr attack. I could be wrong but this seems to be my understanding. The feasability of this attack decreased when W-T (Walkie-Talkie) a half duplex anti-traffic correlation startegy is used. The accuracy with a W-T defense in place is 49% compared to a 90% accuracy with WTF-PAD. Thera There has been a new deep learning attack which is extremely effective against the current implementation of WTF-PAD in Tor. This new attacks is called Deep Fingerprining proposed here : https://arxiv.org/pdf/1801.02265.pdf. Thanks

1 0

[CRITICAL] DeepCorr Traffic Confirmation Attack
by silentguard＠dnmx.org 28 Feb '23

28 Feb '23

Hi, I was just reading a paper on traffic confirmation attacks over here https://arxiv.org/pdf/1808.07285v1.pdf. This attack runs with the help of deep learning algorithm called DeepCorr. This attack can be run in a Five Eyes country or an authoritarian regime like Russia where companies are compelled to cooperate with the government making this attack plausible. The ISP and the website operators are the two endpoints for this attack. This attack was able to achieve a success rate of over 96% which represents a serious threat to Tor users in these regions. The paper also includes some countermeasures on how to defeat this method of traffic confirmation. Thanks.

3 2

A way to connect quickly to a newly-online hidden service?
by Holmes Wilson 23 Feb '23

23 Feb '23

Hi everyone, In the p2p messaging app we're building, Quiet, users exchange some information out-of-band (an onion address) and use that to connect to each other over Tor, as they would for direct messages in Ricochet Refresh or Cwtch. One UX failure we see now is that newly-online hidden services are not available when users first try to connect, so connecting after users have just come online takes unreasonably long (15 minutes or more) and Quiet seems like it's broken. Any thoughts on how to speed up connecting to a newly-online hidden service? One idea we had is to include enough information from the HSDir entry in what peers exchange out-of-band, so that they wouldn't need to rely on finding the HSDir entry. (And if this information became out of date, we could simply encourage users to share information out of band again.) Is there an easy way for us to get this information from Tor on the receiver side and pass it to Tor when connecting? Another idea was to run some service of our own as a fallback, that we knew would always have the latest HSDir entries posted by our users. Is there some straightforward way to hardcode our own HSDir so that Tor would always check it alongside others? If I'm reading the situation wrong or there's some other possibility I'm not thinking of, please let me know! We've definitely observed long delays in onion addresses becoming available, on top of general connection delays, and I'm trying to find a way to improve this situation. Thanks! Holmes

2 1

The future of Tor client software?
by Steven Engler 21 Feb '23

21 Feb '23

Hi tor-dev, In the past, there were generally two options for supporting Tor in an application. 1. Require the user to install the tor daemon (ex: apt install tor, Tor Expert Bundle, etc) and configure the application to use its SOCKS proxy. 2. Bundle the tor binary with the application (ex: Tor Browser) and have the application use the app-specific tor process as the SOCKS proxy. I'm not clear on how this changes in an Arti world. Arti currently has a Rust Tor client library for applications, and a CLI application to run a SOCKS proxy. Is there any plan to offer an Arti daemon (ex: a systemd service) for clients like with the current tor package? In a future where Arti replaces the Tor client and relay code, or when Arti is recommended for all client-related use cases, will there continue to be a Tor daemon with client support? I see various possibilities for developers who wish to use Tor in their applications: 1. Require users to install/run a Tor system service (whether it's tor or arti). - pros: - shared resource usage (mainly circuits) between applications - familiar to experienced Tor users - cons: - requires an additional installation step for users - easy to break by users (for example changing their SOCKS port) - can't modify the Tor client's configuration (ex: can't enable DNSPort, change SocksPort flags, etc) 2. Bundle tor/arti binaries with the application. - pros: - simple for users (no extra configuration needed) - more control over the Tor client's configuration - cons: - can be brittle (ex: an application is already using port 9150) - resources/circuits are not shared between applications - more work for the application developer (needs to build and bundle the tor binary) - (presumably) slower start-up times since there is no pre-existing pool of pending circuits, and descriptors may be out-of-date 3. Use the arti-client library in the application. - pros: - simple for users (no extra configuration needed) - more control over the Tor client's configuration - easy to use for rust application developers - cons: - likely difficult to use in non-rust applications (writing an ffi for the async arti-client API doesn't sound fun) - resources/circuits are not shared between applications - (presumably) slower start-up times since there is no pre-existing pool of pending circuits, and descriptors may be out-of-date 4. Require users to install/run a Tor transparent proxy or TUN adapter. - pros: - should probably "just work" (ex: no SOCKS port that can change or need to be configured) - cons: - requires an additional installation step for users - can't modify the Tor client's configuration - users likely don't want to proxy all their traffic through Tor - slowdowns due to latency from DNS lookups (RELAY_RESOLVE instead of sending the hostname in the RELAY_BEGIN) - no stream isolation support (maybe?) Are there any guidelines for what method should be used under different circumstances? For example using the arti-client library in an email client seems reasonable since a longer startup time while it builds circuits isn't a big deal. But it might be a bad idea to use the arti-client library in cURL, which would need to build circuits each time curl is invoked in a shell script. - Steve

2 3