tor-dev

tor-dev@lists.torproject.org

August 2023

1 participants
2 discussions

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

Prop#344: Prioritizing Protocol Information Leaks in Tor
by Mike Perry 23 Aug '23

23 Aug '23

As part of Sponsor 112, Tor has an objective to address covert channels that malicious relays can use to deanonymize users. This proposal lays the groundwork by categorizing these issues, and prioritizes them according to their severity. Subsequent proposals will deal with specific solutions. I am posting just the intro section of this proposal here. The full proposal is at: https://gitlab.torproject.org/tpo/core/torspec/-/blob/main/proposals/344-pr… Filename: 344-protocol-info-leaks.txt Title: Prioritizing Protocol Information Leaks in Tor Author: Mike Perry Created: 2023-07-17 Purpose: Normative Status: Open 0. Introduction Tor's protocol has numerous forms of information leaks, ranging from highly severe covert channels, to behavioral issues that have been useful in performing other attacks, to traffic analysis concerns. Historically, we have had difficulty determining the severity of these information leaks when they are considered in isolation. At a high level, many information leaks look similar, and all seem to be forms of traffic analysis, which is regarded as a difficult attack to perform due to Tor's distributed trust properties. However, some information leaks are indeed more severe than others: some can be used to remove Tor's distributed trust properties by providing a covert channel and using it to ensure that only colluding and communicating relays are present in a path, thus deanonymizing users. Some do not provide this capability, but can be combined with other info leak vectors to quickly yield Guard Discovery, and some only become dangerous once Guard Discovery or other anonymity set reduction is already achieved. By prioritizing information leak vectors by their co-factors, impact, and resulting consequences, we can see that these attack vectors are not all equivalent. Each vector of information leak also has a common solution, and some categories even share the same solution as other categories. This framework is essential for understanding the context in which we will be addressing information leaks, so that decisions and fixes can be understood properly. This framework is also essential for recognizing when new protocol changes might introduce information leaks or not, for gauging the severity of such information leaks, and for knowing what to do about them. Hence, we are including it in tor-spec, as a living, normative document to be updated with experience, and as external research progresses. It is essential reading material for any developers working on new Tor implementations, be they Arti, Arti-relay, or a third party implementation. This document is likely also useful to developers of Tor-like anonymity systems, of which there are now several, such as I2P, MASQUE, and Oxen. They definitely share at least some, and possibly even many of these issues. Readers who are relatively new to anonymity literature may wish to first consult the Glossary in Section 3, especially if terms such as Covert Channel, Path Bias, Guard Discovery, and False Positive/False Negative are unfamiliar or hazy. There is also a catalog of historical real-world attacks that are known to have been performed against Tor in Section 2, to help illustrate how information leaks have been used adversarially, in practice. We are interested in hearing from journalists and legal organizations who learn about court proceedings involving Tor. We became aware of three instances of real-world attacks covered in Section 2 in this way. Parallel construction (hiding the true source of evidence by inventing an alternate story for the court -- also known as lying) is a possibility in the US and elsewhere, but (so far) we are not aware of any direct evidence of this occurring with respect to Tor cases. Still, keep your eyes peeled... 0.1. Table of Contents 1. Info Leak Vectors 1.1. Highly Severe Covert Channel Vectors 1.1.1. Cryptographic Tagging 1.1.2. End-to-end cell header manipulation 1.1.3. Dropped cells 1.2. Info Leaks that enable other attacks 1.2.1. Handshakes with unique traffic patterns 1.2.2. Adversary-Induced Circuit Creation 1.2.3. Relay Bandwidth Lying 1.2.4. Metrics Leakage 1.2.5. Protocol Oracles 1.3. Info Leaks of Research Concern 1.3.1. Netflow Activity 1.3.2. Active Traffic Manipulation Covert Channels 1.3.3. Passive Application-Layer Traffic Patterns 1.3.4. Protocol or Application Linkability 1.3.5. Latency Measurement 2. Attack Examples 2.1. CMU Tagging Attack 2.2. Guard Discovery Attacks with Netflow Deanonymization 2.3. Netflow Anonymity Set Reduction 2.4. Application Layer Confirmation 3. Glossary The remainder of this proposal can be read at: https://gitlab.torproject.org/tpo/core/torspec/-/blob/main/proposals/344-pr… -- Mike Perry

1 0