February 2024 - tor-dev - lists.torproject.org

When RFC 7686 and transparent proxies collide
by Matt Jolly 28 Sep '24

28 Sep '24

Hello Everyone, I recently inadvertently opened a much larger can of worms than I'd intended when fixing a bug reported downstream where cURL would, when configured with certain DNS backends, fail to resolve .onion addresses. https://bugs.gentoo.org/887287 After doing some digging I discovered that the c-ares library was updated in 2018 to intentionally fail to resolve .onion addresses in line with RFC 7686, and another reported 'Bug' in cURL for leaking .onion DNS requests: https://github.com/c-ares/c-ares/issues/196 https://github.com/curl/curl/issues/543 I took the obviously sane and uncontroversial approach of making sure that cURL would always behave the same way regardless of the DNS backend in use, and that it would output a useful error message when it failed to resolve a .onion address. Unfortunately, this has made a lot of people very angry and been ~~widely regarded as a bad move~~panned by a small subset of downstream cURL users: https://github.com/curl/curl/discussions/11125 https://infosec.exchange/@harrysintonen/110977751446379372 https://gitlab.torproject.org/tpo/core/torspec/-/issues/202 I accept that, in particular, transproxy users are being inconvenienced, but I also don't want to go back to 'cURL leaks .onion DNS requests _sometimes_'. As a career sysadmin and downstream bug triager: this is the stuff that keeps me up late at night. Quite literally, far too often. I have found, however that the downstreams that I expected to be inconvenienced most (Whonix and Tails) simply use socks: https://github.com/Kicksecure/sdwdate/commit/5724d83b258a469b7a9a7bbc651539… https://github.com/Kicksecure/tb-updater/commit/d040c12085a527f4d39cb1751f2… https://github.com/Kicksecure/usability-misc/blob/8f722bbbc7b7f2f3a35619a5a… https://gitlab.tails.boum.org/tails/tails/-/issues/19488 https://gitlab.tails.boum.org/tails/tails/-/merge_requests/1123 I've asked in the Tor Specifications issue (inspired by Silvio's suggestions), and in the cURL issue, but I seem to be getting nowhere and the impacted users are clamouring for a quick band-aid solution, which I feel will work out worse for everyone in the long run: >How can client applications (safely): > >1.discover that they're in a Tor-enabled environment >2.resolve onion services only via Tor in that circumstance >3.not leak .onion resolution attempts at all > >Right now, not making these requests in the first place is the >safest (and correct) thing to do, however inconvenient it may be. >Rather than immediately trying to come up with a band-aid approach >to this problem, a sane mechanism needs to be implemented to: > >1.prevent each application from coming up with their own solution >2.prevent inconsistency in .onion resolution (i.e. no "oh it only >leaks if DO_ONION_RESOLUTION is set") >3.provide a standardised mechanism for applications that want to be Tor >aware to discover that they're in a Tor-enabled environment. I'm not particularly attached to that last point, but it's worth discussing. On a related note: -is the use of a transparent proxy recommended? -is there a sane alternative that involves as minimal configuration as possible for these users? I'm not sure what the best way forward is here, but I'm hoping that actual Tor developers might have a useful opinion on the matter, or at least be able to point me in the right direction. Thanks for your time, Cheers, Matt

7 9

Fact-checking a claim about relay/bridge fingerprint authentication
by David Fifield 25 Feb '24

25 Feb '24

Cecylia, Arlo, Serene, Shelikhoo, and I are writing a research paper about Snowflake. Here is a draft: https://www.bamsoftware.com/papers/snowflake/snowflake.20231003.e6e1c30d.pdf We're writing to check a factual claim in the section about having multiple backend bridges. Basically, we wanted it to be possible for there to be multiple Snowflake bridge sites run by different groups of people, and we did not want to share the same relay identity keys across all bridge sites, because of the increased risk of the keys being exposed. Therefore every bridge site has its own relay identity, which requires the client to know the relay fingerprints in advance and that it be the client (and not, e.g., the broker) that decides which bridge to use. 1. Is our general description (quoted below) of the design constraints as they bear on Tor correct? 2. Is §4.2 "CERTS cells" the right part of tor-spec to cite to make our point? https://gitlab.torproject.org/tpo/core/torspec/-/blob/b345ca044131b2eb18e6a… https://github.com/turfed/snowflake-paper/blob/e6e1c30dde6716dc5e54a32f2134… A Tor bridge is identified by a long-term identity public key. If, on connecting to a bridge, the client finds that the bridge's identity is not the expected one, the client will terminate the connection \cite[\S 4.2]{tor-spec}. The Tor client can configure at most one identity per bridge; there is no way to indicate (with a certificate, for example) that multiple identities should be considered equivalent. This constraint leaves two options: either all Snowflake bridges must share the same cryptographic identity, or else it must be the client that makes the choice of what bridge to use. While the former option is possible to do (by synchronizing identity keys across servers), every added bridge would increase the risk of compromising the all-important identity keys. Our vision was that different bridge sites would run in different locations with their own management teams, and that any compromise of a bridge site should affect that site only. In my own experiments, providing an incorrect relay fingerprint leads to errors in connection_or_client_learned_peer_id: https://gitlab.torproject.org/tpo/core/tor/-/blob/tor-0.4.7.13/src/core/or/… [warn] Tried connecting to router at 192.0.2.3:80 ID=<none> RSA_ID=2B280B23E1107BB62ABFC40DDCC8824814F80A71, but RSA + ed25519 identity keys were not as expected: wanted 1111111111111111111111111111111111111111 + no ed25519 key but got 2B280B23E1107BB62ABFC40DDCC8824814F80A72 + 1zOHpg+FxqQfi/6jDLtCpHHqBTH8gjYmCKXkus1D5Ko. [warn] Problem bootstrapping. Stuck at 14% (handshake): Handshaking with a relay. (Unexpected identity in router certificate; IDENTITY; count 1; recommendation warn; host 1111111111111111111111111111111111111111 at 192.0.2.3:80)

2 3

Re: [tor-dev] UDP Application Support in Tor
by Vilgot Bergquist 13 Feb '24

13 Feb '24

Hi, I looked at the suggested solutions and I think there is another approach, which is much easier. I C it's pretty easy to encapsulate UDP segments inside TCP segments. Hence there is no need to re-organize the connection logic of tor relays. Instead it should be possible to make Guards, when receiving an UDP packet, to just add a TCP header and then it goes through the normal process. The exit nodes than removed the TCP header and pass the UDP segment on. Regards Vilgot tor-dev-request(a)lists.torproject.org <tor-dev-request(a)lists.torproject.org> schrieb am Donnerstag, 25. Januar 2024 um 18:49: > > > Send tor-dev mailing list submissions to > tor-dev(a)lists.torproject.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev > or, via email, send a message with subject or body 'help' to > tor-dev-request(a)lists.torproject.org > > You can reach the person managing the list at > tor-dev-owner(a)lists.torproject.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of tor-dev digest..." > > > Today's Topics: > > 1. New Proposal - UDP Application Support in Tor > (Micah Elizabeth Scott) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Thu, 25 Jan 2024 09:49:02 -0800 > From: Micah Elizabeth Scott beth(a)torproject.org > > To: tor-dev(a)lists.torproject.org > Subject: [tor-dev] New Proposal - UDP Application Support in Tor > Message-ID: 79aa2de8-1ff9-4579-b87f-ee9792e9cbb0(a)torproject.org > > Content-Type: text/plain; charset="utf-8"; Format="flowed" > > Hello tor-dev folks! > > Late last year I started taking a close look at what it would take to > support applications on Tor which rely on UDP networking. This was > originally to be based on Nick's proposal, 339-udp-over-tor. > > The scope of this work so far has been specifically focused on end-user > application compatibility, and excludes fundamental changes to Tor's > network structure or protocols for now. > > This combination of approach and scope left me with more questions than > answers, so I started looking deeper into the available solutions along > with their expected benefits and risks. This proposal is the result of > that investigation. > > Please find the text attached, or in the torspec repo as proposal #348: > > https://gitlab.torproject.org/tpo/core/torspec/-/blob/main/proposals/348-ud… > > Unlike a typical proposal, this does not recommend any specific change > to the Tor implementation. Several possible changes are presented, but > ultimately the recommended approach is to use application-specific UDP > relays to achieve compatibility. > > Integrated approaches are also presented, where Tor does involve itself > in the transit of individual datagrams. These approaches offer > advantages only when they are also part of a long-term plan to offer > transport features beyond those offered by TCP. Until such a plan is > in-scope, specific UDP extensions cannot be offered with confidence. > > I would appreciate any feedback on this proposal, whether it's about > this particular shorter-term context or about longer-term plans to > achieve some kind of optional unreliable transport. > > Thanks for your time! > > --beth >

3 2

Announcing Onionspray 1.6.0 with a SECURITY fix for Onion Services rewriting proxies
by rhatto 09 Feb '24

09 Feb '24

Hello everyone, I'd like to announce Onionspray, a tool for setting up Onion Services for existing public websites, working as a HTTPS rewriting proxy: https://tpo.pages.torproject.net/onion-services/onionspray/ It's a fork of Alec Muffett's EOTK (https://github.com/alecmuffett/eotk) with many enhancements but retaining compatibility, and relying on C Tor until an alternative in Arti is available. The first Onionspray version is 1.6.0, following the pre-existing version sequence from EOTK. Security fixes: * This release fixes a CRITICAL security vulnerability related to upstream HTTPS certificate verification, which is detailed at https://tpo.pages.torproject.net/onion-services/onionspray/security/advisor… A related fix is also available for EOTK: https://github.com/alecmuffett/eotk/pull/116 We urge Onionspray users that were testing the software while it was being on it's early stages to upgrade ASAP to 1.6.0 and update their configurations, and we recommend that EOTK to the same with the corresponding patch. This issue might also affect other similar rewriting proxy setups, and we urge operators to review and fix their Onion Service configurations. Main improvements over EOTK: * MetricsPort support (for gathering metrics data from the tor instances). * Denial of Service (DoS) protections. * Circuit ID exporting to NGINX logs and optionally to the upstream proxy (through the X-Onion-CircuitID HTTP header). * Onionbalance v3 support ("softmaps" are working again). * Revamped documentation. * Installation procedures added for recent Debian and Ubuntu releases. * Tor and OpenResty upgraded to the latest versions. * Option to keep Onionspray running in the foreground (`--no-daemonize`). * Local healthcheck action (`--health-local`), useful for containerized execution. The full ChangeLog is available at https://tpo.pages.torproject.net/onion-services/onionspray/changelog/ For those wishing to switch from EOTK to Onionspray, there's a migration guide at https://tpo.pages.torproject.net/onion-services/onionspray/migrating/ We also welcome people to report issues, send merge requests etc: https://tpo.pages.torproject.net/onion-services/onionspray/contact/ And we have a bunch of issues waiting for contributions: https://gitlab.torproject.org/tpo/onion-services/onionspray/-/issues Finally, I'd like to thank Alec Muffett for his important work with EOTK and for promoting Onion Services all these years :) Thanks! -- Silvio Rhatto pronouns he/him

1 0

docker bridge suddenly fails startup with "Directory /var/lib/tor cannot be read: Permission denied"
by gentle.luck4713＠doublequote.org 01 Feb '24

01 Feb '24

Hi tor-dev@, I have been running a bridge following the instructions at <https://community.torproject.org/relay/setup/bridge/docker/> on a Debian 12.4 system but when I just tried to make sure everything is up to date I got the following error message from docker-compose logs: obfs4-bridge_1 | Using NICKNAME=DockerObfs4Bridge, OR_PORT=3845, PT_PORT=443, and EMAIL=redacted(a)example.com. obfs4-bridge_1 | Additional properties from 'OBFS4V_' environment variables processing enabled obfs4-bridge_1 | Overriding 'AddressDisableIPv6' with value '1' obfs4-bridge_1 | Starting tor. obfs4-bridge_1 | Jan 31 22:49:20.501 [notice] Tor 0.4.8.10 running on Linux with Libevent 2.1.12-stable, OpenSSL 3.0.11, Zlib 1.2.13, Liblzma 5.4.1, Libzstd 1.5.4 and Glibc 2.36 as libc. obfs4-bridge_1 | Jan 31 22:49:20.501 [notice] Tor can't help you if you use it wrong! Learn how to be safe at https://support.torproject.org/faq/staying-anonymous/ obfs4-bridge_1 | Jan 31 22:49:20.501 [notice] Read configuration file "/etc/tor/torrc". obfs4-bridge_1 | Jan 31 22:49:20.502 [notice] Based on detected system memory, MaxMemInQueues is set to 6264 MB. You can override this by setting MaxMemInQueues by hand. obfs4-bridge_1 | Jan 31 22:49:20.503 [notice] Opening OR listener on 0.0.0.0:3845 obfs4-bridge_1 | Jan 31 22:49:20.503 [notice] Opened OR listener connection (ready) on 0.0.0.0:3845 obfs4-bridge_1 | Jan 31 22:49:20.503 [notice] Opening OR listener on [::]:3845 obfs4-bridge_1 | Jan 31 22:49:20.503 [notice] Opened OR listener connection (ready) on [::]:3845 obfs4-bridge_1 | Jan 31 22:49:20.503 [notice] Opening Extended OR listener on 127.0.0.1:0 obfs4-bridge_1 | Jan 31 22:49:20.503 [notice] Extended OR listener listening on port 44595. obfs4-bridge_1 | Jan 31 22:49:20.503 [notice] Opened Extended OR listener connection (ready) on 127.0.0.1:44595 obfs4-bridge_1 | Jan 31 22:49:20.504 [warn] Directory /var/lib/tor cannot be read: Permission denied obfs4-bridge_1 | Jan 31 22:49:20.504 [notice] Closing partially-constructed OR listener connection (ready) on 0.0.0.0:3845 obfs4-bridge_1 | Jan 31 22:49:20.504 [notice] Closing partially-constructed OR listener connection (ready) on [::]:3845 obfs4-bridge_1 | Jan 31 22:49:20.504 [notice] Closing partially-constructed Extended OR listener connection (ready) on 127.0.0.1:44595 obfs4-bridge_1 | Jan 31 22:49:20.504 [warn] Failed to parse/validate config: Couldn't create private data directory "/var/lib/tor" obfs4-bridge_1 | Jan 31 22:49:20.504 [err] Reading config failed--see warnings above. I confirmed that my docker-compose.yaml is unmodified and my .env is innocuous. I know that I can blow away the docker volumes but that'd remove the private keys etc. and that'd doesn't seem desirable. Any advice? Thanks, Hein

1 0