- tor-dev - lists.torproject.org

MSVC compile failure
by Gisle Vanem 21 Mar '23

21 Mar '23

Hello list. Anybody out there? Trying to compile Tor with 'cl' ver. 19.36.32323 from yesterdays 'git master', I got this error in 'src/feature/hs/hs_metrics_entry.c': hs/hs_metrics_entry.c(98,3): error C2099: initializer is not a constant { ^ hs/hs_metrics_entry.c(106,3): error C2099: initializer is not a constant { ^ ---------- This MSVC compiler is rather stupid; it fails to parse that 'static const size_t hs_metrics_circ_build_time_buckets_size' is truly 'const'. No problem with 'clang-cl'. But this patch works: --- a/feature/hs/hs_metrics_entry.c 2023-03-17 18:00:57 +++ b/feature/hs/hs_metrics_entry.c 2023-03-18 13:56:58 @@ -28,8 +28,7 @@ 60000 /* 60s */ }; -static const size_t hs_metrics_circ_build_time_buckets_size = - ARRAY_LENGTH(hs_metrics_circ_build_time_buckets); +#define hs_metrics_circ_build_time_buckets_size ARRAY_LENGTH(hs_metrics_circ_build_time_buckets) ----------------- Just letting you know here. -- --gv

2 3

Cross-user TLS traffic mixing in snowflake-server until 2023-03-13
by David Fifield 15 Mar '23

15 Mar '23

Between 2022-10-01 and 2023-03-13, there was a bug in the software deployed at Snowflake bridges that could cause parts of a user's stream to be overwritten by parts of other users' streams. Though the Snowflake team believes the privacy risks of the bug are minor, we are treating it as a security bug and therefore making this announcement. The fix is already deployed on the server, and no action is required by users. ## The cause The source of the bug was issue https://bugs.torproject.org/tpo/anti-censorship/pluggable-transports/snowfl… and specifically commit https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow…, which was intended as a performance optimization to reduce memory allocation during the large influx of Snowflake users in late September 2022. The analysis surrounding the performance improvement incorrectly concluded that certain memory buffers were not reused and therefore did not need to be copied. But in fact, the buffers were reused, with the effect that data meant for one user could be unpredictably overwritten by data for another user. ## The effect There is analysis at issue https://bugs.torproject.org/tpo/anti-censorship/pluggable-transports/snowfl…. If our understanding of the bug is correct, it did not reveal plaintext data or IP addresses to other users. The Snowflake bridge is a Tor bridge, not an exit relay, so even a catastrophic failure could not leak users' plaintext data or what destinations they were accessing. A Snowflake connection consists of a layered set of protocols, and the bug was in a layer that does not have access to IP addresses or any other persistent identifiers. * IP * TCP * HTTPS (WebSocket) * session/retransmission ← The bug was here * Tor TLS * user data At most, users and proxies would see fragments of other users' Tor TLS streams. We believe the degree of information disclosure is less than what an eavesdropper listening at the Snowflake bridge's HTTPS port would see, which we already believe to be safe. The practical effect, more than a loss of privacy, was excessive retransmissions at the session/retransmission layer, and corrupted TLS data resulting in a terminated connection. ## Remediation We reverted the erroneous commit and added a test to check for the erroneous buffer reuse. We deployed the update to both Snowflake bridges on 2023-03-13. https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… https://bugs.torproject.org/tpo/anti-censorship/pluggable-transports/snowfl… ## Required action No action is required by users. The bug was in code that was only used by the Snowflake server, not proxies or clients. ## Thanks The problem was discovered and first investigated by Haz Æ 41 (https://gitlab.torproject.org/hazae41) and reported on HackerOne: https://hackerone.com/reports/1880610.

1 0

Is Arti expected to have better multi-CPU support than C-tor?
by David Fifield 08 Mar '23

08 Mar '23

Linus Nordberg and I are preparing a submission for FOCI about the special way we run tor on the Snowflake bridge. We run many tor processes with the same identity and onion keys, because otherwise tor being limited to one CPU would be the main bottleneck. I'm writing to fact-check a claim about Arti and how we hope the current complicated procedure will not be needed in the future: The first and most important bottleneck to overcome is the single-threaded nature of the Tor implementation.² A single Tor process is limited to one CPU core: once Tor hits 100% CPU, the performance of the bridge is capped, no matter the speed of the network connection or the number of CPU cores ²We expect that Arti, the in-progress reimplementation of Tor, will be natively multi-threaded, and remove this primary complication. Is this correct? Is a relay that uses a future version of Arti expected to be able to use all its CPU resources? Here is the a draft of the submission. If you have any comments, our submission deadline is 2023-03-15. https://www.bamsoftware.com/papers/pt-bridge-hiperf/pt-bridge-hiperf.202303… https://www.bamsoftware.com/papers/pt-bridge-hiperf/pt-bridge-hiperf.202303…

3 3

[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

Simple tool for mobile remote desktops
by Micah Elizabeth Scott 24 Jan '23

24 Jan '23

Hello, This is an almost trivial utility but I hadn't seen anything quite like it so maybe other folks will find it useful: https://github.com/scanlime/onion-desktop "This is just a toy for now. I wanted to get a feel for the interactive performance of onion services, and it's perhaps sometimes useful if you'd like to share a disposable slice of your computer with a phone when they're both behind NAT. This is a very simple Docker container that runs an xfce4 desktop, novnc, and tor. It will randomly generate a new onion service URL and a VNC password, and show you a tmux with session logs on the left and a big QR code you can scan on the right." Nothing too fancy, just some shell script and Docker and a lot of Debian. The readme has a couple screenshots if you're curious. Cheers, --micah beth

2 1

Proposal 342: Decouple hs_interval and SRV lifetime
by Nick Mathewson 24 Jan '23

24 Jan '23

``` Filename: 342-decouple-hs-interval.md Title: Decoupling hs_interval and SRV lifetime Author: Nick Mathewson Created: 9 January 2023 Status: Draft ``` # Motivation and introduction Tor uses shared random values (SRVs) in the consensus to determine positions of relays within a hash ring. Which shared random value is to be used for a given time period depends upon the time at which that shared random value became valid. But right now, the consensus voting period is closely tied to the shared random value voting cycle: and clients need to understand both of these in order to determine when a shared random value became current. This creates tight coupling between: * The voting schedule * The SRV liveness schedule * The hsdir_interval parameter that determines the length of the an HSDIR index To decouple these values, this proposal describes a forward compatible change to how Tor reports SRVs in consensuses, and how Tor decides which hash ring to use when. ## Reporting SRV timestamps In consensus documents, parties should begin to accept `shared-rand-*-value` lines with an additional argument, in the format of an IsoTimeNospace timestamp (like "1985-10-26T00:00:00"). When present, this timestamp indicates the time at which the given shared random value first became the "current" SRV. Additionally, we define a new consensus method that adds these timestamps to the consensus. We specify that, in the absence of such a timestamp, parties are to assume that the `shared-rand-current-value` SRV became "current" at the first 00:00 UTC on the UTC day of the consensus's valid-after timestamp, and that the `shard-rand-previous-value` SRV became "current" at 00:00 UTC on the previous UTC day. ## Generalizing HSDir index scheduling. Under the current HSDir design, there is one SRV for each time period, and one time period for which each SRV is in use. Decoupling `hsdir_interval` from 24 hours will require that we change this notion slightly. We therefore propose this set of generalized directory behavior rules, which should be equivalent to the current rules under current parameters. The calculation of time periods remains the same (see `rend-spec-v3.txt` section `[TIME PERIODS]`). A single SRV is associated with each time period: specifically, the SRV that was "current" at the start of the time period. There is a separate hash ring associated with each time period and its SRV. Whenever fetching an onion service descriptor, the client uses the hash ring for the time period that contains the start of the liveness interval of the current consensus. Call this the "Consensus" time period. Whenever uploading an onion service descriptor, the service uses _two or three_ hash rings: * The "consensus" time period (see above). * The immediately preceding time period, if the SRV to calculate that hash ring is available in the consensus. * The immediately following time period, if the SRV to calculate that hash ring is available in the consensus. (Under the current parameters, where `hsdir_interval = SRV_interval`, there will never be more than two possible time periods for which the service can qualify.) ## Migration We declare that, for at least the lifetime of the C tor client, we will not make any changes to the voting interval, the SRV interval, or the `hsdir_interval`. As such, we do not need to prioritize implementing these changes in the C client: we can make them in Arti only. ## Issues left unsolved There are likely other lingering issues that would come up if we try to change the voting interval. This proposal does not attempt to solve them. This proposal does not attempt to add flexibility to the SRV voting algorithm itself. Changing `hsdir_interval` would create a flag day where everybody using old and new values of `hsdir_interval` would get different hash rings. We do not try to solve that here. ## Acknowledgments Thanks to David Goulet for explaining all of this stuff to me!

4 7

Tor Bridges and Snowflakes detection attack
by tor＠nullvoid.me 09 Jan '23

09 Jan '23

Hi, https://github.com/scriptzteam/Tor-Bridges-Collector Seems an attacker has found a way to enumerate ~300000 snowflakes and many bridges. I couldn't find any discussion about this in the archive. Thanks,

4 4