- tor-dev - lists.torproject.org

Proposal 350: A phased plan to remove TAP onion keys
by Nick Mathewson 31 May '24

31 May '24

``` Filename: 350-remove-tap.md Title: A phased plan to remove TAP onion keys Author: Nick Mathewson Created: 31 May 2024 Status: Open ``` ## Introduction Back in [proposal 216], we introduced the `ntor` circuit extension handshake. It replaced the older `TAP` handshake, which was badly designed, and dependent on insecure key lengths (RSA1024, DH1024). With the [final shutdown of v2 onion services][hsv2-deprecation], there are no longer any supported users of TAP anywhere in the Tor protocols. Anecdotally, a relay operator reports that fewer than one handshake in 300,000 is currently TAP. (Such handshakes are presumably coming from long-obsolete clients.) Nonetheless, we continue to bear burdens from TAP support. For example: - TAP keys compose a significant (but useless!) portion of directory traffic. - The TAP handshake requires cryptographic primitives used nowhere else in the Tor protocols. Now that we are implementing [relays in Arti], the time is ripe to remove TAP. (The only alternative is to add a useless TAP implementation in Arti, which would be a waste of time.) This document outlines a plan to completely remove the TAP handshake, and its associated keys, from the Tor protocols. This is, in some respects, a modernized version of [proposal 245]. ## Migration plan Here is the plan in summary; we'll discuss each phase below. - Phase 1: Remove TAP dependencies - Item 1: Stop accepting TAP circuit requests. - Item 2: Make TAP keys optional in directory documents. - Item 3: Publish dummy TAP keys. - Phase 2: After everybody has updated - Item 1: Allow TAP-free routerdescs at the authorities - Item 2: Generate TAP-free microdescriptors - Phase 3: Stop publishing dummy TAP keys. Phase 1 can begin immediately. Phase 2 can begin once all supported clients and relays have upgraded to run versions with the changes made in Phase 1. Phase 3 can begin once all authorities have made the changes described in phase 2. ### Phase 1, Item 1: Stop accepting TAP circuit requests. (All items in phase 1 can happen in parallel.) Immediately, Tor relays should stop accepting TAP requests. This includes all CREATE cells (not CREATE2), and any CREATE2 cell whose type is TAP (0x0000). When receiving such a request, relays should respond with DESTROY. Relays MAY just drop the request entirely, however, if they find that they are getting too many requests. Such relays must stop reporting `Relay=1` among their supported protocol versions. (This protocol version is not currently required or recommended.) > If this proposal is accepted, > we should clarify the protocol version specification > to say that `Relay=1` specifically denotes TAP. ### Phase 1, Item 2: Make TAP keys optional in directory documents. (All items in phase 1 can happen in parallel.) In C tor and Arti, we should make the `onion-key` entry and the `onion-key-crosscert` entry optional. (If either is present, the other still must be present.) When we do this, we should also modify the authority code to reject any descriptors that do not have these fields. (This will be needed so that existing Tor instances do not break.) In the microdescriptor documents format, we should make the _object_ of the `onion-key` element optional. (We do not want to make the element itself optional, since it is used to delimit microdescriptors.) We use new protocol version flags (Desc=X, Routerdesc=Y) to note the ability to parse these documents. ### Phase 1, Item 3: Publish dummy TAP keys (All items in phase 1 can happen in parallel.) Even after step 2 is done, many clients and relays on the network will still require TAP keys to be present in directory documents. Therefore, we can't remove those keys right away. Relays, therefore, must put _some_ kind of RSA key into their `onion-key` field. I'll present three designs on what relays should do. We should pick one. > #### Option 1 (conservative) > > Maybe, we should say that a relay > should generate a TAP key, generate an onion-key-crosscert, > and then discard the private component of the key. > #### Option 2 (low-effort) > > In C tor, we can have relays simply proceed as they do now, > maintaining TAP private keys and generating crosscerts. > > This has little real risk beyond what is described in Option 1. > #### Option 3 (nutty) > > We _could_ generate a global, shared RSA1024 private key, > to be used only for generating onion-key-crosscerts > and placing into the onion-key field of a descriptor. > > We would say that relays publishing this key MUST NOT > actually handle any TAP requests. > > The advantage of this approach over Option 1 > would be that we'd see gains in our directory traffic > immediately, since all identical onion keys would be > highly compressible. > > The downside here is that any client TAP requests > sent to such a relay would be decryptable by anybody, > which would expose long-obsolete clients to MITM attacks > by hostile guards. We would control the presence of these dummy TAP keys using a consensus parameter: `publish-dummy-tap-key` — If set to 1, relays should include a dummy TAP key in their routerdescs. If set to 0, relays should omit the TAP key and corresponding crosscert. (Min: 0, Max, 1, Default: 0.) We would want to ensure that all authorities voted for this parameter as "1" before enabling support for it at the relay level. ### Phase 2, Item 1: Allow TAP-free routerdescs at the authorities Once all clients and relays have updated to a version where the `onion-key` router descriptor element is optional (see phase 1, item 2), we can remove the authority code that requires all descriptors to have TAP keys. ### Phase 2, Item 2: Generate TAP-free microdescriptors Once all clients and descriptors have updated to a version where the `onion-key` body is optional in microdescriptors (see phase 1, item 2), we can add a new consensus method in which authorities omit the body when generating microdescriptors. ### Phase 3: Stop publishing dummy TAP keys. Once all authorities have stopped requiring the `onion-key` element in router descriptors (see phase 2, item 1), we can disable the `publish-dummy-tap-key` consensus parameter, so that relays will no longer include TAP keys in their router descriptors. [proposal 216]: ./216-ntor-handshake.txt [proposal 245]: ./245-tap-out.txt [hsv2-deprecation]: https://support.torproject.org/onionservices/v2-deprecation/ [relays in Arti]: https://gitlab.torproject.org/tpo/team/-/wikis/Sponsor%20141

2 1

Key Blinding Secrets
by Bellebaum, Thomas 04 May '24

04 May '24

Hello everyone, I am a researcher currently looking into different schemes for what you call Keyblinding in the rendevouz spec. https://spec.torproject.org/rend-spec/keyblinding-scheme.html I noticed that your description there mentiones a secret `s` to be hashed into the blinding factor, and have a few questions about it: 1. Is this secret currently being used / intended to be used? If so, how? 2. What kinds of security (formally or informally) would you expect from using a secret in the derivation process? For example, do you just require that someone without `s` cannot look up the service, or is this also meant as a way of ensuring that HSDir nodes cannot find correlations between services and descriptors (amounting to some sort of additional censorship resistance)? The reason I am asking is because my research has identified some potentially post quantum secure schemes which for unknown identity keys results in uncorrelatable blinded keys, but where for known public keys you can efficiently determine whether a blinded key is its derivative, even if you do not know the blinding factor. I am wondering for which kinds of applications (with TOR being a major one) this would be relevant. If you have any insights, please let me know. Also I am new to the TOR-Dev world, so feel free to send me to a different mailing list, should I have chosen the wrone one for this topic :) Thanks in advance, Thomas -- ``` M.Sc. Thomas Bellebaum Applied Privacy Technologies Fraunhofer Institute for Applied and Integrated Security AISEC Lichtenbergstraße 11, 85748 Garching near Munich (Germany) Tel. +49 89 32299 86 1039 thomas.bellebaum(a)aisec.fraunhofer.de https://www.aisec.fraunhofer.de ```

2 1

Proposal for Tor (Relay) Watchdog (Telegram) Bot
by Alessandro Greco 29 Apr '24

29 Apr '24

Dear Tor Project Developers, I hope this email finds you well. I am writing to share with you a project [1] I have been working on called Tor Watchdog Bot [2], and I believe it may be of interest to you. Tor Watchdog Bot is a Telegram bot designed to monitor the status of Tor relays and notify users when relays go offline. The intent behind creating this bot was to develop a user-friendly tool that allows anyone to easily keep track of their Tor nodes. I am fully aware that the bot is not currently ready for public release as it requires several bug fixes and improvements. Before proceeding with further development, I wanted to ensure that this project aligns with your interests and goals. In order to prioritize user privacy and security, I did not activate the backend feature with the actual functionality; instead, I activated a demo that always provides the same results but allows users to understand the type of response they would receive if it were active. In the README.md file, you will find detailed instructions on how to set up and test the bot. If you find this project interesting and believe it could be beneficial to the Tor community, I would be delighted to see Tor Project host this service. However, I understand the importance of avoiding any form of user profiling, so I want to ensure that any potential hosting solution prioritizes user privacy. The code for Tor Watchdog Bot is released under the GPLv3 license, so you are libre to use and modify it as you see fit. I would be thrilled to contribute to the development of this project if it aligns with your vision. Thank you for considering this proposal. I look forward to hearing your thoughts and feedback. Best regards, Aleff. [1] https://github.com/aleff-github/TorWatchdog [2] https://t.me/TorWatchdog_bot --- Browse my WebSite: aleff-gitlab.gitlab.io Use my PGP Public Key: pgp.mit.edu/pks/lookup?op=get&search=0x7CFCE404A2168C85 Join to support: - Free Software Foundation! (my.fsf.org/join?referrer=6202114) - Electronic Frontier Foundation! (eff.org) - Tor-Project (torproject.org) - Signal (signal.org)

2 1

Proposal #349: Command state validation (for dropmark attacks)
by Mike Perry 07 Mar '24

07 Mar '24

We've merged a draft of Proposal #349 to torspec: https://gitlab.torproject.org/tpo/core/torspec/-/blob/main/proposals/349-co… Also available on the tor spec site at: https://spec.torproject.org/proposals/349-command-state-validation.html This proposal is meant to deal with the third class of highly severe protocol side channels in tor: Dropped Cells. See Prop #344 for background: https://spec.torproject.org/proposals/344-protocol-info-leaks.html Note that there still are some details that need to be ironed out wrt how and when to perform checks that depend upon full parsing and protocol context, as opposed to just relay message command. This work is part of Sponsor 112; arti-client support is due by EOY 2024. C-Tor will not implement this proposal. -- Mike Perry

1 0

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

New Proposal - UDP Application Support in Tor
by Micah Elizabeth Scott 25 Jan '24

25 Jan '24

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

1 0

Timers in Arti?
by Michael Rogers 15 Jan '24

15 Jan '24

Hi, If I understand right, the C implementation of Tor has various state machines that are driven by local libevent timers as well as events from the network. For example, when building a circuit, if there hasn't been any progress for a certain amount of time then a timer fires to handle the timeout. When running Tor on Android, we need to prevent the OS from suspending so that these timers fire when they're supposed to. This uses a lot of battery, because normally the OS would spend most of its time suspended. Unlike a laptop, an Android device with its screen turned off is constantly dipping in an out of suspension, and a lot of the platform's power optimisations are aimed at batching whatever work needs to be done so that the periods of suspension can be longer. If we allowed the OS to suspend then the timers would fire with arbitrary delays, and I don't really know what impact that would have: I'd speculate that there might be connectivity problems (eg dead circuits not being detected and replaced) and/or network-visible changes in the behaviour of circuits that could affect anonymity. So I've had a longstanding but not-very-hopeful request that maybe Tor's reliance on timers could be reduced, or at least clarified, so that we could either allow the OS to suspend without breaking anything, or at least know what was likely to break. And basically I'd just like to renew that request for Arti. Could anyone give me an overview of how these local timers are handled in Arti, or any information about what's likely to happen if the timers are arbitrarily delayed? Thanks, Michael

4 8