June 2023 - tor-dev - lists.torproject.org

What happens to my hidden service?
by Liste 29 Dec '25

29 Dec '25

Hidden service is unavailable, but tor is running. Tor's log: Dec 12 18:10:27.000 [notice] Your Guard SECxFreeBSD64 ($D7DB8E82604F806766FC3F80213CF719A0481D0B) is failing more circuits than usual. Most likely this means the Tor network is overloaded. Success counts are 199/285. Use counts are 101/101. 253 circuits completed, 0 were unusable, 54 collapsed, and 15 timed out. For reference, your timeout cutoff is 60 seconds. is failing a very large amount of circuits. Most likely this means the Tor network is overloaded, but it could also mean an attack against you or potentially the guard itself. Dec 12 18:15:53.000 [warn] Giving up launching first hop of circuit to rendezvous point [scrubbed] for service xxxxxxxxxxxxxxx. Dec 11 13:08:59.000 [notice] We'd like to launch a circuit to handle a connection, but we already have 32 general-purpose client circuits pending. Waiting until some finish. [268 similar message(s) suppressed in last 600 seconds] Dec 11 13:43:12.000 [warn] onion_skin_client_handshake failed. Dec 11 13:43:12.000 [warn] circuit_finish_handshake failed. Dec 11 13:43:12.000 [warn] connection_edge_process_relay_cell (at origin) failed. Dec 11 00:34:57.000 [warn] Giving up launching first hop of circuit to rendezvous point [scrubbed] for service .... Dec 10 10:09:01.000 [warn] rend_service_introduce(): Bug: Internal error: Got an INTRODUCE2 cell on an intro circ (for service "...") with no corresponding rend_intro_point_t. Dec 10 10:09:03.000 [warn] rend_service_introduce(): Bug: Internal error: Got an INTRODUCE2 cell on an intro circ (for service "...") with no corresponding rend_intro_point_t. Dec 10 10:09:04.000 [warn] rend_service_introduce(): Bug: Internal error: Got an INTRODUCE2 cell on an intro circ (for service "...") with no corresponding rend_intro_point_t. Dec 10 12:42:19.000 [warn] rend_service_introduce(): Bug: Internal error: Got an INTRODUCE2 cell on an intro circ (for service "...") with no corresponding rend_intro_point_t.

3 2

Network Status APIs
by Mattia Righetti 22 Jun '23

22 Jun '23

Greetings Tor devs, In an effort to improve current resource utilisation, the Network Health Status team is developing a new version of their pipeline [1]. Previously, much of the data was stored on files, this made many operations slow due to their I/O bound nature. The new pipeline will transfer much of the data related to Tor nodes and bridges from files stored on a single server's disk to two separate databases: Postgres and Victoria Metrics. With this new approach, there's the need to develop a new service that is going to replace the current onionoo web protocol [2]. The main objective of this project is to design a RESTful API service, using the actix_web framework, that is going to be integrated in the new pipeline v2.0 to support data retrieval of bridges and relays from the two databases and additionally provide new features such as historic data search. The project will be developed over the next few weeks as part of the GSoC sponsored program. Please do reach out to me, hiro or GeKo if you have any ideas or feedback you'd like to share with us. Cheers, Matt [1] https://gitlab.torproject.org/tpo/network-health/team/-/wikis/metrics/colle… [2] https://gitlab.torproject.org/tpo/network-health/metrics/networkstatusapi/

1 0

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