- tor-dev - lists.torproject.org

Arti development report: July 7 through July 21
by Nick Mathewson 21 Jul '21

21 Jul '21

# Arti Report 2: July 7 through July 21 It's been a quiet couple of weeks. Most of the team has been on vacation or leave for the last two weeks, so the Arti hacking has been down to me (nick) for this period. Our last report went out on the same day that our [announcement] went public, and since then we've had an influx of attention and volunteers interest. Thanks to everybody who's been trying out the code! Special thanks to `trinity-1686a` for a [stream-isolation] implementation, `lyuyuan` for work on [RESOLVE and RESOLVE_PTR][resolve], and everybody else who's been submitting patches! ## Circuit timeout inference My own work for this period has focused on [circuit timeout inference][cti]. (I decided to start with this because it's part of the Tor protocol that I've worked with the least in the past.) The approach is kind of complicated: in order to adjust our timeout, we need to observe how long circuits actually take to complete... including the circuits that we don't use because they take longer than our current timeout timeout. So we have to keep building circuits for a while even after they time out, so that we can observe how long it takes them to finish. Then we use an estimator based on a Pareto distribution, and use that to determine our actual cutoffs. The core logic is now [implemented in Arti][pareto-code], and we just have a few more pieces ([persistence][ticket-143], [directory notification][ticket-144], and [testing circuits][ticket-145]) to cover before we can call it done. ## Open problems Our timeout tests rely on using a simulated view of time. (Nobody wants to wait 10 seconds for a simulated 10-second timeout!) For that, we have [testing code][rt-mock-time] to override the asynchronous runtime's view of the passage of time. But we have a bug somewhere that makes these tests unreliable. The [WaitFor] future, which is supposed to run a another future to completion while advancing the current (simulated) time, doesn't seem to be reliable. As implemented, it advances the current time even when the future it's testing _isn't_ blocked on time, and sometimes advances time much too far while the tested future makes no progress. I've kludged it up by making it yield a lot and advance time in tiny increments, but that's just a workaround. Does anybody like [debugging Futures code][ticket-149]? ## Next steps In the next two weeks I hope we can wrap up the outstanding issues above in circuit timeouts, including the ones that require some architectural decisions. I'm also hoping that we can make progress on [guards]: that's the last remaining really big security feature we have to do for our 0.0.1 milestone. Once that's done, we can move on to polishing and infrastructure issues for the rest of the time we have for this milestone. Finally, we're going to be expanding our team! Please have a look at our [job-opening], and share it with anybody you know who is interested in Rust and Tor, and who might be interested in a job. Next update in two weeks! [announcement]: https://blog.torproject.org/announcing-arti [cti]: https://gitlab.torproject.org/tpo/core/torspec/-/blob/master/path-spec.txt#… [cti]: https://gitlab.torproject.org/tpo/core/torspec/-/blob/master/guard-spec.txt [job-opening]: https://www.torproject.org/about/jobs/rust-dev/ [pareto-code]: https://gitlab.torproject.org/tpo/core/arti/-/blob/main/tor-circmgr/src/tim… [resolve]: https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/39 [rt-mock-time]: https://gitlab.torproject.org/tpo/core/arti/-/blob/main/tor-rtmock/src/time… [stream-isolation]: https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/38 [ticket-143]: https://gitlab.torproject.org/tpo/core/arti/-/issues/143 [ticket-144]: https://gitlab.torproject.org/tpo/core/arti/-/issues/144 [ticket-145]: https://gitlab.torproject.org/tpo/core/arti/-/issues/145 [ticket-149]: https://gitlab.torproject.org/tpo/core/arti/-/issues/149 [WaitFor]: https://gitlab.torproject.org/tpo/core/arti/-/blob/main/tor-rtmock/src/slee…

1 0

Weaving a Faster Tor: paper/video of possible interest
by Ian Goldberg 20 Jul '21

20 Jul '21

Hello tor-dev, Steve Engler (currently part of the Shadow team) and I have a paper of possible interest to appear at ARES 2021 next month. It's a design of a multi-threaded relay architecture, of possible particular interest when considering relay support in arti, for example (though the proof-of-concept implementation is based on the usual C codebase). If you're interested, here are previews of: Paper: https://cs.uwaterloo.ca/~iang/pubs/mttor-ares21.pdf Video: https://www.youtube.com/watch?v=41a6nLUJye8 Code: https://git-crysp.uwaterloo.ca/sengler/tor-parallel-relay-conn https://git-crysp.uwaterloo.ca/sengler/relay-throughput-testing -- Ian Goldberg Canada Research Chair in Privacy Enhancing Technologies Professor, Cheriton School of Computer Science University of Waterloo

4 4

GSoC 2021 - Alexa Top Sites Captcha and Tor Block Monitoring #Update
by Apratim Ranjan Chakrabarty 20 Jul '21

20 Jul '21

Hi everyone! Been quite sometime since the last update but if one wants to see the details in between one could go to the DIAL blogs for the project[1]. As of now, we do have a working project with the following details implemented [2] and further the dotted[consensus module], idea taken from Senser paper[3] haven't been implemented yet, but hopefully I'll implement it within a week or two at most. I personally was tilted towards the similarity of the structure but after some discussions with woswos and Micah Sherr[4], I've thought of implementing the content based approach too. I'll briefly describe both the methods below: + Structure of the website: This was thought of because we don't really know what various changes would be there for a website. More specifically would be useful for dynamic websites, websites with language based on geolocation (Geotargeting). But I have to use a filter list and statistical method to approach the problem. + Content based Approach: Compares the content of the HTML data using tree like structure and hashes to know how the structure is different or similar. Usage of proxies of the same locations as vantage points to get better results. That said, the above mentioned methods are used for the case where websites partially block tor. One good example for this case would be https://dan.me.uk/ which doesn't block tor exit relay nodes completely, but gives an error page (partial block) and no error HTTP response code. The checking of the HTTP response codes being a low-hanging-fruitish algorithm is our first step which is seen performing good and might sometimes result in false positives (Says a website like https://cloudflare.com to be blocked completely, when it returns captcha or is partially blocked). Further for the demo purpose, one can refer to the Experimental code[5] and it's log[6] (Isn't much of a good code and is a bit old but wrote to serve the purpose of backing up the first method (Structure of the website)). Also one could look into the `Analyzer.py`[7,8] which would contain the most recent and improved logic to the analysis. Hope to improve it with every passing day. I also plan to create a FAQ[9] page which would have excerpts of discussions or answers to as why a following approach was taken. Thanks, Apratim (irc: _ranchak_) ** Looking forward for suggestions and comments as to how to improve on it. Also materials like research paper in this domain would be helpful ** References: [1] https://hub.osc.dial.community/t/tor-project-alexa-top-sites-captcha-and-bl… [2] https://gitlab.torproject.org/woswos/CAPTCHA-Monitor/-/wikis/GSoC-2021#upda… [3] http://people.cs.georgetown.edu/~wzhou/publication/senser-acsac13.pdf [4] https://seclab.cs.georgetown.edu/msherr/ [5] https://github.com/Hackhard/Fetcher/blob/b9f2fa8d09061862cf954537cbaad7921d… [6] https://raw.githubusercontent.com/Hackhard/Fetcher/main/status%20code/test_… [7] Consensus_lite branch: https://gitlab.torproject.org/woswos/CAPTCHA-Monitor/-/blob/consensus_lite/… [8] Master branch: https://gitlab.torproject.org/woswos/CAPTCHA-Monitor/-/blob/master/src/capt… [9] https://gitlab.torproject.org/woswos/CAPTCHA-Monitor/-/wikis/GSoC-2021/Faqs

2 1

Mostly Automatic Censorship Circumvention in Tor Browser
by Richard Pospesel 08 Jul '21

08 Jul '21

Hi Everyone, As part of our Sponsor 30 work, we are looking to improve the new about:torconnect experience by adding automatic tor settings configuration for censorship circumvention. This document outlines and discusses the *technical* challenges associated with this work, and does not go into any great detail on the right UX would be (in terms of easy of use, user trust, etc). Anyway, if you see any pitfalls or problems with anything here, do let us know. ------------------------------8<-------------------------------------- # Mostly Automatic Bridge Configuration to Bypass Internet Censorship Our goal for this work is to enable Tor Browser users to access tor without having to navigate to about:preferences#tor to configure bridges. Technically speaking, this is a trivial problem assuming you know: - which bridge settings work at the user's location - the location of the user ## Circumvention Settings Map For now, it seems sufficient to maintain a map of countries to some data-structure containing information about which censorship circumvention techniques work and which ones do not. A proposed example format can be found here: - https://gitlab.torproject.org/tpo/anti-censorship/state-of-censorship/-/blo… This map would at be distributed and updated through tor-browser releases. ### Problems #### Censorship Changes Invalidate the Map The obvious problem with distributing the censorship-circumvention settings map with Tor Browser is that if the techniques used in a location change such that old settings no longer work, you will be left with a non-functional Tor Browser with no way to update it apart from acquiring a fresh install with the updated settings or by manually configuring Tor Browser's bridge settings (so what users have to do now) A fix for this would be to provide a rules update mechanism whereby updated rules could be fetched outside of tor (via the clearnet, or over moat). Special care would need to be taken to ensure the rule updates from this automatic mechanism actually came from the Tor Project (via some sort of signature verification scheme, for example). Another wrinkle here is that rules would also need to be distributed somewhere that is difficult to censor. It seems likely that we may need different locations and mechanisms for acquiring the rule-set based on the user's location. Whatever the mechanism, updates should happen at least before the user attempts to auto-configure. Otherwise, perhaps we should periodically auto-update the the settings at a reasonable cadence. #### Time Investment to Update Map Another problem with solely distributing the rules through Tor Browser, is that censorship events would now require a Tor Browser release just to push new rules out to people. Publishing new Tor Browser releases is not a simple task, and enabling adversaries to force Tor Browser releases by tweaking their censorship systems seems like a cute way to DDOS the Applications team. An alternate update channel is definitely necessary outside of periodic Tor Browser releases. #### Are Per-Country Entries Granular Enough? One could imagine highly localized censorship events occurring which require special settings that are not needed in the rest of the country. For instance, if there is a clearnet blackout in Minneapolis, would we want to pipe *all* of our US users through the same bridges? Seems like a potential scalability problem for countries with large populations. ## Determining User Location A user's location can be determined by accessing location services through the clearnet. Mozilla offers a such a service ( https://location.services.mozilla.com/ ) with a very simple HTTP interface. Prior to bootstrapping, Tor Browser can access the location service by temporarily enabling network DNS: - network.dns.disabled=false and making an exception for the location service URL to bypass the proxy by: - network.proxy.no_proxies_on="location.services.mozilla.com" The location service would send back a country code in a JSON object which we can use to look up appropriate bridge settings in our map described above. ### Problems So the functionality of this approach is pretty easy to implement: tweak some prefs, make an XMLHttpRequest, change the prefs back. One possible problem we may face is if censors start blocking Mozilla's location services. Maybe we should have a pool of location service providers to make this more difficult (though we would need to do the research and figure out how feasible this is from a cost perspective). It is also possible to add location service functionality to moat, though this would also be a bit of an engineering endeavor. If we move forward with Mozilla's location services, we will need to acquire an API key, but I would not expect this to be an issue. We will also need to make arrangements with them to surpass the current limit of 100,000 daily API requests ( see: https://location.services.mozilla.com/terms ) The big challenge here is engineering the right UX which maintains our users trust. I think we need to be very explicit with this convenience feature, and definitely not just have it silently happen in the background. Users should also be able to opt-out, and manually select their country for the purposes of getting the right settings out of the above mentioned map. It should be very difficult to accidentally enable this automatic lookup. This will likely require a fair bit of iteration on the about:torconnect page design and flow.

2 1

Arti development report: 23 June through July 7
by Nick Mathewson 08 Jul '21

08 Jul '21

# Arti Report 1: 23 June through July 7 We started with a project kickoff meeting. We're planning to continue meeting every 2 weeks, making our meetings increasingly public, and posting them on youtube. We wrote up an announcement to explain what Arti is and why we're doing it. The [announcement](https://blog.torproject.org/announcing-arti) goes live on July 8; it's a good place to start if you're not already familiar with the project, or if you're looking for more helpful links. To get ready for future development, and check the state of our packages we put out an [0.0.0 release](https://crates.io/crates/arti) and uploaded it to crates.io. We found a couple of issues while doing so ([#129][ticket-129], [#130][ticket-130]). We want to switch as much new-feature development to Arti as we can. With that in mind, we're developing a set of guidelines for discouraging features in C -- especially features with the potential to destabilize our code. (See [#128][ticket-128].) We're trying a bottom-up approach here, starting by identifying what kinds of features we've done recently that maybe we should skip in the future. We had an excellent meeting with developers on various Zcash projects, to gather requirements, set expectations, and open lines of communication. Based on their suggestions, we opened a set of new tickets to work on. ([#132][ticket-132] [#133][ticket-133] [#134][ticket-134] [#135][ticket-135] [#136][ticket-136] [#137][ticket-137] [#138][ticket-138] [#139][ticket-139] [#140][ticket-140]) In terms of new code written, things have been a bit slow: we're still ramping up, and a lot of folks take vacations in the summer. We [revised our asynchronous runtime backend][ticket-129] based on issues we found while uploading our packages. More recently, I've started working on an [implementation][ticket-57] of Tor's [circuit timeout inference][cti] code, which is necessary for good performance and security. ## Next steps In our next couple of weeks, I hope we get a first cut at our circuit timeout code finished and working, and figure out a reasonable initial solution for our [persistence needs][ticket-59]. We'll also be ramping up on implementations for [guard nodes][ticket-58] and [stream isolation][ticket-73], both of which are necessary for security. [ticket-57]: https://gitlab.torproject.org/tpo/core/arti/-/issues/57 [ticket-58]: https://gitlab.torproject.org/tpo/core/arti/-/issues/58 [ticket-59]: https://gitlab.torproject.org/tpo/core/arti/-/issues/59 [ticket-73]: https://gitlab.torproject.org/tpo/core/arti/-/issues/73 [ticket-128]: https://gitlab.torproject.org/tpo/core/arti/-/issues/128 [ticket-129]: https://gitlab.torproject.org/tpo/core/arti/-/issues/129 [ticket-130]: https://gitlab.torproject.org/tpo/core/arti/-/issues/130 [ticket-132]: https://gitlab.torproject.org/tpo/core/arti/-/issues/132 [ticket-133]: https://gitlab.torproject.org/tpo/core/arti/-/issues/133 [ticket-134]: https://gitlab.torproject.org/tpo/core/arti/-/issues/134 [ticket-135]: https://gitlab.torproject.org/tpo/core/arti/-/issues/135 [ticket-136]: https://gitlab.torproject.org/tpo/core/arti/-/issues/136 [ticket-137]: https://gitlab.torproject.org/tpo/core/arti/-/issues/137 [ticket-138]: https://gitlab.torproject.org/tpo/core/arti/-/issues/138 [ticket-139]: https://gitlab.torproject.org/tpo/core/arti/-/issues/139 [ticket-140]: https://gitlab.torproject.org/tpo/core/arti/-/issues/140 [cti]: https://gitlab.torproject.org/tpo/core/torspec/-/blob/master/path-spec.txt#…

1 0

Build HS Circuit
by David Willis 27 Jun '21

27 Jun '21

Hi I'm doing a research project into onions and I'm trying to add a control port command to build a HS circuit. I see EXTENDCIRC can create normal circs, but how would I modify it a to build a HS circuit? Assuming I've already HSFETCHed it. I don't wait to initiate a socks request, just build the circuit and wait. It isn't quite clear to me where in the code base onion circuits are built or how, and how to initiate one. Would be grateful even for high-level instructions. Thanks David University of Singapore Sent with [ProtonMail](https://protonmail.com/) Secure Email.

1 0

[RFC] Proposal: "Res tokens: Anonymous Credentials for Onion Service DoS Resilience"
by George Kadianakis 13 Jun '21

13 Jun '21

Hello all, after lots of investigation on anonymous credentials, we are glad to present you with a draft of the onion services anti-DoS proposal using tokens. While the basic idea of the proposal should remain reasonably solid, there are various XXX sprinkled around the proposal and some of them definitely need to be addressed before the proposal becomes truly usable. We are particularly looking forward to feedback about: - Token issuance services - The anonymous credential scheme chosen - The XXXs and design decisions of the proposal Hope you have a pleasant read! --- ``` Filename: 331-res-tokens-for-anti-dos.md Title: Res tokens: Anonymous Credentials for Onion Service DoS Resilience Author: George Kadianakis, Mike Perry Created: 11-02-2021 Status: Draft ``` +--------------+ +------------------+ | Token Issuer | | Onion Service | +--------------+ +------------------+ ^ ^ | +----------+ | Issuance | 1. | | 2. | Redemption +------->| Alice |<-------+ | | +----------+ # 0. Introduction This proposal specifies a simple anonymous credential scheme based on Blind RSA signatures designed to fight DoS abuse against onion services. We call the scheme "Res tokens". Res tokens are issued by third-party issuance services, and are verified by onion services during the introduction protocol (through the INTRODUCE1 cell). While Res tokens are used for denial of service protection in this proposal, we demonstrate how they can have application in other Tor areas as well, like improving the IP reputation of Tor exit nodes. # 1. Motivation Denial of service attacks against onion services have been explored in the past and various defenses have been proposed: - Tor proposal #305 specifies network-level rate-limiting mechanisms. - Onionbalance allows operators to scale their onions horizontally. - Tor proposal #327 increases the attacker's computational requirements (not implemented yet). While the above proposals in tandem should provide reasonable protection against many DoS attackers, they fundamentally work by reducing the assymetry between the onion service and the attacker. This won't work if the attacker is extremely powerful because the assymetry is already huge and cutting it down does not help. we believe that a proposal based on cryptographic guarantees -- like Res tokens -- can offer protection against even extremely strong attackers. # 2. Overview In this proposal we introduce an anonymous credential scheme -- Res tokens -- that is well fitted for protecting onion services against DoS attacks. We also introduce a system where clients can acquire such anonymous credentials from various types of Token Issuers and then redeem them at the onion service to gain access even when under DoS conditions. In section [TOKEN_DESIGN], we list our requirements from an anonymous credential scheme and provide a high-level overview of how the Res token scheme works. In section [PROTOCOL_SPEC], we specify the token issuance and redemption protocols, as well as the mathematical operations that need to be conducted for these to work. In section [TOKEN_ISSUERS], we provide a few examples and guidelines for various token issuer services that could exist. In section [DISCUSSION], we provide more use cases for Res tokens as well as future improvements we can conduct to the scheme. # 3. Design [TOKEN_DESIGN] In this section we will go over the high-level design of the system, and on the next section we will delve into the lower-level details of the protocol. ## 3.1. Anonymous credentials Anonymous credentials or tokens are cryptographic identifiers that allow their bearer to maintain an identity while also preserving anonymity. Clients can acquire a token in a variety of ways (e.g. registering on a third-party service, solving a CAPTCHA, completing a PoW puzzle) and then redeem it at the onion service proving this way that work was done, but without linking the act of token acquisition with the act of token redemption. ## 3.2. Anonymous credential properties The anonymous credential literature is vast and there are dozens of credential schemes with different properties [REF_TOKEN_ZOO], in this section we detail the properties we care about for this use case: - Public Verifiability: Because of the distributed trust properties of the Tor network, we need anonymous credentials that can be issued by one party (the token issuer) and verified by a different party (in this case the onion service). - Perfect unlinkability: Unlinkability between token issuance and token redemption is vital in private settings like Tor. For this reason we want our scheme to preserve its unlinkability even if its fundamental security assumption is broken. We want unlinkability to be protected by information theoretic security or random oracle, and not just computational security. - Small token size: The tokens will be transfered to the service through the INTRODUCE1 cell which is not flexible and has only a limited amount of space (about 200 bytes) [REF_INTRO_SPACE]. We need tokens to be small. - Quick Verification: Onions are already experiencing resource starvation because of the DoS attacks so it's important that the process of verifying a token should be as quick as possible. In section [TOKEN_PERF] we will go deeper into this requirement. After careful consideration of the above requirements, we have leaned towards using Blind RSA as the primitive for our tokens, since it's the fastest scheme by far that also allows public verifiability. See also Appendix B [BLIND_RSA_PROOF] for a security proof sketch of Blind RSA perfect unlinkability. ## 3.3. Other security considerations Apart from the above properties we also want: - Double spending protection: We don't want Malory to be able to double spend her tokens in various onion services thereby amplifying her attack. For this reason our tokens are not global, and can only be redeemed at a specific destination onion service. - Metadata: We want to encode metadata/attributes in the tokens. In particular, we want to encode the destination onion service and an expiration date. For more information see section [DEST_DIGEST]. For blind RSA tokens this is usually done using "partially blind signatures" but to keep it simple we instead encode the destination directly in the message to be blind-signed and the expiration date using a set of rotating signing keys. - One-show: There are anonymous credential schemes with multi-show support where one token can be used multiple times in an unlinkable fashion. However, that might allow an adversary to use a single token to launch a DoS attack, since revocation solutions are complex and inefficient in anonymous credentials. For this reason, in this work we use one-show tokens that can only be redeemed once. That takes care of the revocation problem but it means that a client will have to get more tokens periodically. ## 3.4. Res tokens overview Throughout this proposal we will be using our own token scheme, named "Res", which is based on blind RSA signatures. In this modern cryptographic world, not only we have the audacity of using Chaum's oldest blind signature scheme of all times, but we are also using RSA with a modulus of 1024 bits... The reason that Res uses only 1024-bits RSA is because we care most about small token size and quick verification rather than the unforgeability of the token. This means that if the attacker breaks the issuer's RSA signing key and issues tokens for herself, this will enable the adversary to launch DoS attacks against onion services, but it won't allow her to link users (because of the "perfect unlinkability" property). Furthermore, Res tokens get a short implicit expiration date by having the issuer rapidly rotate issuance keys every few hours. This means that even if an adversary breaks an issuance key, she will be able to forge tokens for just a few hours before that key expires. For more ideas on future schemes and improvements see section [FUTURE_RES]. ## 3.5. Token performance requirements [TOKEN_PERF] As discussed above, verification performance is extremely important in the anti-DoS use case. In this section we provide some concrete numbers on what we are looking for. In proposal #327 [REF_POW_PERF] we measured that the total time spent by the onion service on processing a single INTRODUCE2 cell ranges from 5 msec to 15 msecs with a mean time around 5.29 msec. This time also includes the launch of a rendezvous circuit, but does not include the additional blocking and time it takes to process future cells from the rendezvous point. We also measured that the parsing and validation of INTRODUCE2 cell ("top half") takes around 0.26 msec; that's the lightweight part before the onion service decides to open a rendezvous circuit and do all the path selection and networking. This means that any defenses introduced by this proposal should add minimal overhead to the above "top half" procedure, so as to apply access control in the lightest way possible. For this reason we implemented a basic version of the Res token scheme in Rust and benchmarked the verification and issuance procedure [REF_RES_BENCH]. We measured that the verification procedure from section [RES_VERIFY] takes about 0.104 ms, which we believe is a reasonable verification overhead for the purposes of this proposal. We also measured that the issuance procedure from [RES_ISSUANCE] takes about 0.614 ms. # 4. Specification [PROTOCOL_SPEC] +--------------+ +------------------+ | Token Issuer | | Onion Service | +--------------+ +------------------+ ^ ^ | +----------+ | Issuance | 1. | | 2. | Redemption +------->| Alice |<-------+ | | +----------+ ## 4.0. Notation Let `a || b` be the concatenation of a with b. Let `a^b` denote the exponentiation of a to the bth power. Let `a == b` denote a check for equality between a and b. Let FDH_N(msg) be a Full Domain Hash (FDH) of 'msg' using SHA256 and stretching the digest to be equal to the size of an RSA modulus N. ## 4.1. Token issuer setup The Issuer creates a set of ephemeral RSA-1024 "issuance keys" that will be used during the issuance protocol. Issuers will be rotating these ephemeral keys every 6 hours. The Issuer exposes the set of active issuance public keys through a REST HTTP API that can be accessed by visiting /issuers.keys. Tor directory authorities periodically fetch the issuer's public keys and vote for those keys in the consensus so that they are readily available by clients. The keys in the current consensus are considered active, whereas the ones that have fallen off have expired. XXX how many issuance public keys are active each time? how does overlapping keys work? clients and onions need to know precise expiration date for each key. this needs to be specified and tested for robustness. XXX every how often does the fetch work? how does the voting work? which issuers are considered official? specify consensus method. XXX An alternative approach: Issuer has a long-term ed25519 certification key that creates expiring certificates for the ephemeral issuance keys. Alice shows the certificate to the service to prove that the token comes from an issuer. The consensus includes the long-term certification key of the issuers to establish ground truth. This way we avoid the synchronization between dirauths and issuers, and the multiple overlapping active issuance keys. However, certificates might not fit in the INTRODUCE1 cell (prop220 certs take 104 bytes on their own). Also certificate metadata might create a vector for linkability attacks between the issuer and the verifier. ## 4.2. Onion service signals ongoing DoS attack When an onion service is under DoS attack it adds the following line in the "encrypted" (inner) part of the v3 descriptor as a way to signal to its clients that tokens are required for gaining access: "token-required" SP token-type SP issuer-list NL [At most once] token-type: Is the type of token supported ("res" for this proposal) issuer: A comma separated list of issuers which are supported by this onion service ## 4.3. Token issuance When Alice visits an onion service with an active "token-required" line in its descriptor it checks whether there are any tokens available for this onion service in its token store. If not, it needs to acquire some and hence the token issuance protocol commences. ### 4.3.1. Client preparation [DEST_DIGEST] Alice first chooses an issuer supported by the onion service depending on her preferences by looking at the consensus and her Tor configuration file for the current list of active issuers. After picking a supported issuer, she performs the following preparation before contacting the issuer: 1) Alice extracts the issuer's public key (N,e) from the consensus 2) Alice computes a destination digest as follows: dest_digest = FDH_N(destination || salt) where: - 'destination' is the 32-byte ed25519 public identity key of the destination onion - 'salt' is a random 32-byte value, 3) Alice samples a blinding factor 'r' uniformly at random from [1, N) 4) Alice computes: blinded_message = dest_digest * r^e (mod N) After this phase is completed, Alice has a blinded message that is tailored specifically for the destination onion service. Alice will send the blinded message to the Token Issuer, but because of the blinding the Issuer does not get to learn the dest_digest value. XXX Is the salt needed? Reevaluate. ### 4.3.3. Token Issuance [RES_ISSUANCE] Alice now initiates contact with the Token Issuer and spends the resources required to get issued a token (e.g. solve a CAPTCHA or a PoW, create an account, etc.). After that step is complete, Alice sends the blinded_message to the issuer through a JSON-RPC API. After the Issuer receives the blinded_message it signs it as follows: blinded_signature = blinded_message ^ d (mod N) where: - 'd' is the private RSA exponent. and returns the blinded_signature to Alice. XXX specify API (JSON-RPC? Needs SSL + pubkey pinning.) ### 4.3.4. Unblinding step Alice verifies the received blinded signature, and unblinds it to get the final token as follows: token = blinded_signature * r^{-1} (mod N) = blinded_message ^ d * r^{-1] (mod N) = (dest_digest * r^e) ^d * r^{-1} (mod N) = dest_digest ^ d * r * r^{-1} (mod N) = dest_digest ^ d (mod N) where: - r^{-1} is the multiplicative inverse of the blinding factor 'r' Alice will now use the 'token' to get access to the onion service. By verifying the received signature using the issuer keys in the consensus, Alice ensures that a legitimate token was received and that it has not expired (since the issuer keys are still in the consensus). ## 4.4. Token redemption ### 4.4.1. Alice sends token to onion service Now that Alice has a valid 'token' it can request access to the onion service. It does so by embedding the token into the INTRODUCE1 cell to the onion service. To do so, Alice adds an extension to the encrypted portion of the INTRODUCE1 cell by using the EXTENSIONS field (see [PROCESS_INTRO2] section in rend-spec-v3.txt). The encrypted portion of the INTRODUCE1 cell only gets read by the onion service and is ignored by the introduction point. We propose a new EXT_FIELD_TYPE value: [02] -- ANON_TOKEN The EXT_FIELD content format is: TOKEN_VERSION [1 byte] ISSUER_KEY [4 bytes] DEST_DIGEST [32 bytes] TOKEN [128 bytes] SALT [32 bytes] where: - TOKEN_VERSION is the version of the token ([0x01] for Res tokens) - ISSUER_KEY is the public key of the chosen issuer (truncated to 4 bytes) - DEST_DIGEST is the 'dest_digest' from above - TOKEN is the 'token' from above - SALT is the 32-byte 'salt' added during blinding This will increase the INTRODUCE1 payload size by 199 bytes since the data above is 197 bytes, the extension type and length is 2 extra bytes, and the N_EXTENSIONS field is always present. According to ticket #33650, INTRODUCE1 cells currently have more than 200 bytes available so we should be able to fit the above fields in the cell. XXX maybe we don't need to pass DEST_DIGEST and we can just derive it XXX maybe with a bit of tweaking we can even use a 1536-bit RSA signature here... ### 4.4.2. Onion service verifies token [RES_VERIFY] Upon receiving an INTRODUCE1 cell with the above extension the service verifies the token. It does so as follows: 1) The service checks its double spend protection cache for an element that matches DEST_DIGEST. If one is found, verification fails. 2) The service checks: DEST_DIGEST == FDH_N(service_pubkey || SALT), where 'service_pubkey' is its own long-term identity pubkey. 3) The service finds the corresponding issuer pubkey 'e' based on ISSUER_KEY from the consensus or its configuration file 4) The service checks: TOKEN ^ e == DEST_DIGEST Finally the onion service adds the DEST_DIGEST to its double spend protection cache to avoid the same token getting redeemed twice. Onion services keep a double spend protection cache by maintaining a sorted array of truncated DEST_DIGEST elements. If any of the above steps fail, the verification process aborts and the introduction request gets discarded. If all the above verification steps have been completed successfully, the service knows that this a valid token issued by the token issuer, and that the token has been created for this onion service specifically. The service considers the token valid and the rest of the onion service protocol carries out as normal. # 5. Token issuers [TOKEN_ISSUERS] In this section we go over some example token issuers. While we can have official token issuers that are supported by the Tor directory authorities, it is also possible to have unofficial token issuers between communities that can be embedded directly into the configuration file of the onion service and the client. In general, we consider the design of token issuers to be independent from this proposal so we will touch the topic but not go too deep into it. ## 5.1. CAPTCHA token issuer A use case resembling the setup of Cloudflare's PrivacyPass would be to have a CAPTCHA service that issues tokens after a successful CAPTCHA solution. Tor Project, Inc runs https://ctokens.torproject.org which serves hCaptcha CAPTCHAs. When the user solves a CAPTCHA the server gives back a list of tokens. The amount of tokens rewarded for each solution can be tuned based on abuse level. Clients reach this service via a regular Tor Exit connection, possibly via a dedicated exit enclave-like relay that can only connect to https://ctokens.torproject.org. Upon receiving tokens, Tor Browser delivers them to the Tor client via the control port, which then stores the tokens into a token cache to be used when connecting to onion services. In terms of UX, most of the above procedure can be hidden from the user by having Tor Browser do most of the things under the scenes and only present the CAPTCHA to the user if/when needed (if the user doesn't have tokens available for that destination). XXX specify control port API between browser and tor ## 5.2. PoW token issuer An idea that mixes the CAPTCHA issuer with proposal#327, would be to have a token issuer that accepts PoW solutions and provides tokens as a reward. This solution tends to be less optimal than applying proposal#327 directly because it doesn't allow us to fine-tune the PoW difficulty based on the attack severity; which is something we are able to do with proposal#327. However, we can use the fact that token issuance happens over HTTP to introduce more advanced PoW-based concepts. For example, we can design token issuers that accept blockchain shares as a reward for tokens. For example, a system like Monero's Primo could be used to provide DoS protection and also incentivize the token issuer by being able to use those shares for pool mining [REF_PRIMO]. ## 5.3. Onion service self-issuing The onion service itself can also issue tokens to its users and then use itself as an issuer for verification. This way it can reward trusted users by giving it tokens for the future. The tokens can be rewarded from within the website of the onion service and passed to the Tor Client through the control port, or they can be provided in an out-of-bands way for future use (e.g. from a journalist to a future source using a QR code). Unfortunately, the anonymous credential scheme specified in this proposal is one-show, so the onion service cannot provide a single token that will work for multiple "logins". In the future we can design multi-show credential systems that also have revocation to further facilitate this use case (see [FUTURE_RES] for more info). # 6. User Experience This proposal has user facing UX consequences. Ideally we want this process to be invisible to the user and things to "just work". This can be achieved with token issuers that don't require manual work by the user (e.g. the PoW issuer, or the onion service itself), since both the token issuance and the token redemption protocols don't require any manual work. In the cases where manual work is needed by the user (e.g. solving a CAPTCHA) it's ideal if the work is presented to the user right before visiting the destination and only if it's absolutely required. An explanation about the service being under attack should be given to the user when the CAPTCHA is provided. # 7. Security In this section we analyze potential security threats of the above system: - An evil client can hoard tokens for hours and unleash them all at once to cause a denial of service attack. We might want to make the key rotation even more frequent if we think that's a possible threat. - A trusted token issuer can always DoS an onion service by forging tokens. - Overwhelming attacks like "top half attacks" and "hybrid attacks" from proposal#327 is valid for this proposal as well. - A bad RNG can completely wreck the linkability properties of this proposal. XXX Actually analyze the above if we think there is merit to listing them # 8. Discussion [DISCUSSION] ## 8.1. Using Res tokens on Exit relays There are more scenarios within Tor that could benefit from Res tokens however we didn't expand on those use cases to keep the proposal short. In the future, we might want to split this document into two proposals: one proposal that specifies the token scheme, and another that specifies how to use it in the context of onion servicves, so that we can then write more proposals that use the token scheme as a primitive. An extremely relevant use case would be to use Res tokens as a way to protect and improve the IP reputation of Exit relays. We can introduce an exit pool that requires tokens in exchange for circuit streams. The idea is that exits that require tokens will see less abuse, and will not have low scores in the various IP address reputation systems that now govern who gets access to websites and web services on the public Internet. We hope that this way we will see less websites blocking Tor. ## 8.2. Future improvements to this proposal [FUTURE_RES] The Res token scheme is a pragmatic scheme that works for the space/time constraints of this use case but it's far from ideal for the greater future (RSA? RSA-1024?). After Tor proposal#319 gets implemented we will be able to pack more data in RELAY cells and that opens the door to token schemes with bigger token sizes. For example, we could design schemes based on BBS+ that can provide more advanced features like multi-show and complex attributes but currently have bigger token sizes (300+ bytes). That would greatly improve UX since the client won't have to solve multiple CAPTCHAs to gain access. Unfortunately, another problem here is that right now pairing-based schemes have significantly worse verification performance than RSA (e.g. in the order of 4-5 ms compared to <0.5 ms). We expect pairing-based cryptography performance to only improve in the future and we are looking forward to these advances. When we switch to a multi-show scheme, we will also need revocation support otherwise a single client can abuse the service with a single multi-show token. To achieve this we would need to use blacklisting schemes based on accumulators (or other primitives) that can provide more flexible revocation and blacklisting; however these come at the cost of additional verification time which is not something we can spare at this time. We warmly welcome research on revocation schemes that are lightweight on the verification side but can be heavy on the proving side. ## 8.3. Other uses for tokens in Tor There is more use cases for tokens in Tor but we think that other token schemes with different properties would be better suited for those. In particular we could use tokens as authentication mechanisms for logging into services (e.g. acquiring bridges, or logging into Wikipedia). However for those use cases we would ideally need multi-show tokens with revocation support. We can also introduce token schemes that help us build a secure name system for onion services. We hope that more research will be done on how to combine various token schemes together, and how we can maintain agility while using schemes with different primitives and properties. # 9. Acknowledgements Thanks to Jeff Burdges for all the information about Blind RSA and anonymous credentials. Thanks to Michele Orrù for the help with the unlinkability proof and for the discussions about anonymous credentials. Thanks to Chelsea Komlo for pointing towards anonymous credentials in the context of DoS defenses for onion services. --- # Appendix A: RSA Blinding Security Proof [BLIND_RSA_PROOF] This proof sketch was provided by Michele Orrù: ``` RSA Blind Sigs: https://en.wikipedia.org/wiki/Blind_signature#Blind_RSA_signatures As you say, blind RSA should be perfectly blind. I tried to look at Boneh-Shoup, Katz-Lindell, and Bellare-Goldwasser for a proof, but didn't find any :( The basic idea is proving that: for any message "m0" that is blinded with "r0^e" to obtain "b" (that is sent to the server), it is possible to freely choose another message "m1" that blinded with another opening "r1^e" to obtain the same "b". As long as r1, r0 are chosen uniformly at random, you have no way of telling if what message was picked and therefore it is *perfectly* blind. To do so: Assume the messages ("m0" and "m1") are invertible mod N=pq (this happens at most with overwhelming probability phi(N)/N if m is uniformly distributed as a result of a hash, or you can enforce it at signing time). Blinding happens by computing: b = m0 * (r0^e). However, I can also write: b = m0 * r0^e = (m1/m1) * m0 * r0^e = m1 * (m0/m1*r0^e). This means that r1 = (m0/m1)^d * r0 is another valid blinding factor for b, and it's distributed exactly as r0 in the group of invertibles (it's unif at random, because r0 is so). ``` --- [REF_TOKEN_ZOO]: https://tokenzoo.github.io/ [REF_INTRO_SPACE]: https://gitlab.torproject.org/legacy/trac/-/issues/33650#note_2350910 [REF_CHAUM]: https://eprint.iacr.org/2001/002.pdf [REF_PRIMO]: https://repo.getmonero.org/selene/primo https://www.monerooutreach.org/stories/RPC-Pay.html [REF_POW_PERF]: https://gitlab.torproject.org/tpo/core/torspec/-/blob/master/proposals/327-… [REF_RES_BENCH]: https://github.com/asn-d6/res_tokens_benchmark

5 5

[RFC] Proposal 332: Vanguards lite
by George Kadianakis 01 Jun '21

01 Jun '21

Hello list, I present you with a simplified version of prop292 which protects against guard discovery attacks. The proposal can also be found in: https://gitlab.torproject.org/asn/torspec/-/commits/vg-lite --- ``` Filename: 332-vanguards-lite.md Title: Vanguards lite Author: George Kadianakis, Mike Perry Created: 2021-05-20 Status: Draft ``` # 0. Introduction & Motivation This proposal specifies a simplified version of Proposal 292 "Mesh-based vanguards" for the purposes of implementing it directly into the C Tor codebase. For more details on guard discovery attacks and how vanguards defend against it, we refer to Proposal 292 [PROP292_REF]. # 1. Overview We propose an identical system to the Mesh-based Vanguards from proposal 292, but with the following differences: - No third layer of guards is used. - The Layer2 lifetime uses the max(x,x) distribution with a minimum of one day and maximum of 12 days. This makes the average lifetime approximately a week. We let NUM_LAYER2_GUARDS=4. - We don't write guards on disk. This means that the guard topology resets when tor restarts. By avoiding a third-layer of guards we reduce the linkability issues of Proposal 292, which means that we don't have to add an extra hop on top of our paths. This simplifies engineering. # 2. Rotation Period Analysis From the table in Section 3.1 of Proposal 292, with NUM_LAYER2_GUARDS=4 it can be seen that this means that the Sybil attack on Layer2 will complete with 50% chance in 18*7 days (126 days) for the 1% adversary, 4*7 days (one month) for the 5% adversary, and 2*7 days (two weeks) for the 10% adversary. # 3. Tradeoffs from Proposal 292 This proposal has several advantages over Proposal 292: By avoiding a third-layer of guards we reduce the linkability issues of Proposal 292, which means that we don't have to add an extra hop on top of our paths. This simplifies engineering and makes paths shorter by default: this means less latency and quicker page load times. This proposal also comes with disadvantages: The lack of third-layer guards makes it easier to launch guard discovery attacks against clients and onion services. Long-lived services are not well protected, and this proposal might provide those services with a false sense of security. Such services should still use the vanguards addon [VANGUARDS_REF]. # 4. References [PROP292_REF]: https://gitlab.torproject.org/tpo/core/torspec/-/blob/main/proposals/292-me… [VANGUARDS_REF]: https://github.com/mikeperry-tor/vanguards

1 0

Renaming the primary branch of tor.git
by Alexander Færøy 25 May '21

25 May '21

Hello! As of today, the primary development branch of tor.git (the Git repository containing the source code of Tor) is now named 'main'. If you use tor.git in your tools, where you refer to the branch names, you probably want to change that to 'main' right away, otherwise your tools may break. All existing Gitlab MR's should have been updated to target the new primary branch name, but contributors should make sure their local checkouts are tracking main now for updates. Tor.git maintainers should re-run the usual scripts and make sure their work tree setup uses 'main'. All the best, Alex. -- Alexander Færøy

1 0

GSoC 2021 - Alexa Top Sites Captcha and Tor Block Monitoring
by Apratim Ranjan Chakrabarty 24 May '21

24 May '21

Hello everyone, I'm Apratim (irc: _ranchak_), and I'm from Haldia Institute of Technology, India, studying Computer Science Engineering. I'll be working this summer on the GSoC project: "Alexa Top Sites Captcha and Tor Block Monitoring" with my mentors Barkin, Pili, Gerog and Roger guiding me through the irc. I'm very excited to be a part of Tor and am interested in working on this project! Briefing about the project: As of now "The Captcha Monitoring" project tracks how often CDN (for ex. Cloudflare, Akamai, Amazon Cloudfront, etc.) fronted webpages return CAPTCHAs to Tor clients. My project will be focussed on tracking the The Alexa Top 500 Websites, to give a detailed perspective of websites mentioned in the Topsites, blocking or returning Captchas to Tor clients. The project aims to do so by fetching webpages over a period of time from both Tor clients/browsers and the non-tor browsers thereby comparing the results. The results will be then collected and provide answers to the different metrics, and also form an understanding of how websites are blocking Tor and affect Internet freedom. Also one could visit: https://gitlab.torproject.org/woswos/CAPTCHA-Monitor/-/wikis/GSoC-2021 for detailed info. As planned and discussed by my mentor, I'll be creating more issues, which could be seen from the sidebar along the wiki page, to record my progress. As of now one could reach out with suggestions and advises in the irc (#tor-dev) as well as here: tpo/community/support/#40013. I also plan to update my wiki page frequently and have all the information required. Hope to have a great learning ahead and enjoy this summer! Regards, Apratim

2 2

Consensus network status fetch
by sysmanager7 16 May '21

16 May '21

Why does a network status fetch cause a signal hup and my system to reset? 00:30:35 [NOTICE] While not bootstrapping, fetched this many bytes: 17796869 (server descriptor x fetch); 8622 (server descriptor upload); 2216044 (consensus network-status fetch); 148431 x (microdescriptor fetch) x 00:00:07 [NOTICE] Read configuration file "/etc/tor/torrc". x 00:00:07 [NOTICE] Read configuration file "/usr/share/tor/tor-service-defaults-torrc". x 00:00:07 [NOTICE] Received reload signal (hup). Reloading config and resetting internal state. xlq May 13, 2021 qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqk Sent with [ProtonMail](https://protonmail.com) Secure Email.

2 3

descriptor sync finished event after disabling UseMicrodescritors
by nusenu 16 May '21

16 May '21

Hi, what is the best way to find out when descriptor fetching is completed after temporarily disabling microdescriptors on a running tor client daemon? The temporary disabling of microdescriptors is done using this line in a python script using stem: controller.set_conf('UseMicrodescriptors', '0') Is there a better way than to try and re-try after 10 seconds in a loop via controller.get_server_descriptors() ? I also noticed that fetching takes significantly longer when microdescriptors are disabled temporarily when compared to adding UseMicrodescriptors 0 to the torrc file persistently and restarting the tor client. Can I tell tor to "fetch now" directly after controller.set_conf('UseMicrodescriptors', '0') via an additional control command? kind regards, nusenu -- https://nusenu.github.io

3 3

Uptime stats for "Tor user can access an otherwise-functional hidden service"?
by Holmes Wilson 06 May '21

06 May '21

Hi everyone, I’m building a messaging app based on Tor v3 onion services and I’m wondering what kind of uptime expectations we should set with users and other stakeholders. Is there data over time on uptime for onion service functionality? That is, not for a particular onion service, but for something like, given that the user’s access to Tor is not being limited by their ISP, and given that the onion service is fully operational, whether a Tor user can reach the onion service? Some more concrete versions of this question are: 1. For what percentage of time over a given time period (say the past 3 years) are there no known network-wide problems affecting onion services? 2. What percentage of attempts by a user attempting to connect to a onion service are successful, assuming no successful censorship of the user’s network? 3. Is there some incident log somewhere of problems that affected onion services network wide that includes how long these problems persisted for? (I don’t see any onion service outage notes in this document, though I seem to remember there was an issue a few months back? https://metrics.torproject.org/news.html <https://metrics.torproject.org/news.html>) I see there’s uptime data for various relays, but I’m not sure how to translate this into a meaningful answer to the two above questions. Are there any good answers to these questions out there in the wild? Even approximate answers or lower bounds for uptime are fine and super helpful! Thanks!!! Holmes

3 3

What's the best way to learn about critical updates to Tor?
by Holmes Wilson 06 May '21

06 May '21

Hi all, For the messaging app we’re building on Tor (not Tor browser) what’s the best way for us to be alerted when there are critical updates to Tor, so that we can prepare a new release as quickly as possible? (Apologies for the flurry of questions today!) Holmes

2 1

ClientAuthV3 for v3 onions via Tor controller is accepted by ADD_ONION but seems to get ignored
by Miguel Jacq 04 May '21

04 May '21

Hi there, I'm one of the OnionShare developers and I'm trying to implement the new support for ClientAuthV3 via the controller as per [1] (thanks for adding it!). Since OnionShare depends on Stem, I also began by adding support for passing the ClientAuthV3 argument and V3Auth flag into Stem (I intend on submitting that as a PR once I solve the problem below, but I think the problem isn't Stem specific) I can send the ClientAuthV3 base32-encoded public key and the V3Auth flag to ADD_ONION, and get a 250 response back. The problem is that when I then visit the onion address, it doesn't actually require the Client Auth that was set :) I am running the nightly Tor on Debian 10 (Buster): ``` Tor version 0.4.7.0-alpha-dev. Tor is running on Linux with Libevent 2.1.8-stable, OpenSSL 1.1.1d, Zlib 1.2.11, Liblzma 5.2.4, Libzstd 1.3.8 and Glibc 2.28 as libc. Tor compiled with GCC version 8.3.0 ``` Steps to reproduce: 1) Take these public and private base32-encoded strings (as generated by [2], if you want to generate different ones) public: FGTORMIDKR7T2PR632HSHLWA4G6HF5TCWSGMHDUU4LWBEFTAVYQQ private: 5ZTNYVGHGMBCWT47YQT4ZFOFBWYU24C5PRQZ2CRCXZ5FKTVMJ7QA 2) Start a simple service on localhost:9735: ``` echo Hi | nc -l 127.0.0.1 9735 ``` 3) Connect to Tor's control port and add an onion with a private key that will derive the onion address rujvluxdgiibem3odopgkgiiajgtwfbdgkuqfyydhl5qupotpwyxjaid.onion (or put your own if you wish): ``` user@onionshare:~$ sudo telnet localhost 9051 Trying ::1... Trying 127.0.0.1... Connected to localhost. Escape character is '^]'. authenticate "" 250 OK ADD_ONION ED25519-V3:MNkxu0oI0CX6Oq1AEroRGSAiqXurEbzBdraDKJB1pkNkl9hNCr+bagdAg7gA4F3M/FrF7BHBdh5zdvkHB7oO4w== ClientAuthV3=FGTORMIDKR7T2PR632HSHLWA4G6HF5TCWSGMHDUU4LWBEFTAVYQQ Flags=V3Auth Port=80,9735 250-ServiceID=rujvluxdgiibem3odopgkgiiajgtwfbdgkuqfyydhl5qupotpwyxjaid 250-ClientAuthV3=AUEFTXH34ZVRXIIVOK5G7XLHTUXGVRLLXG7DG3NKJLRCVSEEHQDQ 250 OK ``` 4) Visit http://rujvluxdgiibem3odopgkgiiajgtwfbdgkuqfyydhl5qupotpwyxjaid.onion and expect to get the Tor Browser pop-up dialog '[onion service] is requesting that you authenticate.. Enter your private key for this onion service'. etc Instead: the service loads 'Hi' without any requirement for Client Auth occurring. I never added the private key to Tor Browser in any way. Is it a bug, or am I doing it wrong somehow? Thanks! mig5 [1] https://gitlab.torproject.org/tpo/core/tor/-/issues/40084 [2] https://github.com/pastly/python-snippits/blob/master/src/tor/x25519-gen.py

2 2

Free and Open Communications on the Internet (FOCI) submission deadline May 13
by Roger Dingledine 22 Apr '21

22 Apr '21

Hi folks! The FOCI workshop is happening again this year, organized by our friends Eric Wustrow (Tapdance, Conjure) and Dave Levin (Geneva). The deadline for submissions is May 13. Cecylia, Arturo, me, Alberto from IODA, Tariq, Rob, phw, etc are all on the program committee: https://conferences.sigcomm.org/sigcomm/2021/workshop-foci.html So: if you have something you want to share with the FOCI audience, consider writing it down and submitting. :) Thanks! --Roger

1 0

Hackathon UDP Support
by Matthew Finkel 14 Apr '21

14 Apr '21

Hello! During the Hackweek, I spent a little time hacking support of UDP-over-Tor. The goal of the project was supporting UDP onion services, and leaving Exit support for another time. I didn't have a working implementation by the end of the week, but life moves one. This is an initial mail about the general idea, and I'll follow up with a concrete proposal in the not-too-distant future. I have a (currently broken) branch `feature_udp_data` in my gitlab repo [0]. I started simplifying/refactoring the hack job, but it's still a work in progress. I'll briefly describe how the working version [1] is designed. Overall, this mostly just-works. While UDP is not a reliable routed protocol, datagrams are not dropped within the network. We delegate drops to the edges' recv/send queues (and any intermediate network equipment). Client Side: The patch continued our dependence on SOCKS5 [2] and (maybe correctly) implemented the UDP ASSOCIATE command. The client sends a normal SOCKS5 handshake, except the new command is 0x03. The tor client then: - Establishes a rendezvous circuit with the specified onion service hostname in the handshake - On completing that connection, creates and binds a datagram socket - Sends the application a Success response and includes the datagram socket's bound address and port in that message. The client then sends all datagrams to the provided (bound) address:port, and the TCP socket used in the SOCKS5 handshake is only kept open as a way of tracking the UDP socket's lifetime. Tor knows that any datagram payload should be transported as a datagram instead of a stream. Tor Internal: The patch introduces two relay cell commands: DATAGRAM and DATAGRAM_FRAG. These relay cell types are stateless. Simply, when a tor client (or general edge, in the future) receives a DATAGRAM_FRAG relay cell, it knows that the payload is only a fragment of an entire datagram. As a result, tor queues the data and does not send it to the application. When a DATAGRAM cell is received, then tor knows the contained payload is either: 1) a complete datagram that fit into a single relay cell 2) the final payload of a fragmented datagram In either case, tor appends the payload to the (possibly empty) queue and then sends it to the application. Tor doesn't need to care which one is the current case. Also, Tor doesn't take into account a MTU mismatch between the client-side and server-side - future work. As an aside, I considered introducing only a single DATAGRAM relay cell, and reserving the first byte for metadata (and using a bit indicating if the payload is a fragment). However, I couldn't convince myself that losing one byte of payload capacity was worth the advantages. I'll leave this as a valuable discussion during the proposal process. Onion Service Side: The onion service is configured normally, except now there is a HiddenServiceType configuration option. When it isn't provided, the default value is "stream", otherwise it should be "dgram". This configuration tells tor that a "stream" opened to this onion service (on the specified port) is actually connectionless, and any payload data should be sent and received as datagrams. Following from the previous section, when a DATAGRAM relay cell is received, the queued payload is packaged as a datagram and sent to the configured onion service address:port. Future design considerations: - Better client-side interface than SOCKS5 UDP Associate? - Relay cell design improvements - Cleaner onion service configuration? - MTU difference on the client/server-sides - What's missing before we can support this on Exits? [0] https://gitlab.torproject.org/sysrqb/tor/ [1] commit ebfb4a97713d49a5e7f61709658b9d55ac21ec95 [2] https://tools.ietf.org/html/rfc1928

1 0

Question about hidden services shared by multiple hosts
by Holmes Wilson 10 Apr '21

10 Apr '21

Hi everyone, We’re working on a peer-to-peer group chat app where peers connect over v3 onion addresses. One issue are groups where there are many users but only a few are online in a given moment. Onion addresses are forever, and existing peers might know every peer in the network, but it will take a while to try connecting to all of them to find one that is online. In this case, it seems helpful for one or more peers to share one or more onion addresses that would serve as reliable “trackers", e.g. 1. All members know the keypairs for these addresses. 2. All online members ping these addresses at random intervals to say they’re online. 3. If they can’t connect to an address, they start hosting it themselves. We’re going to start testing it, but we’re wondering if folks here know the likely outcome of trying to “share” hosting of an onion service in this spontaneous-volunteer sort of way and if there are downsides. I *think* the most important question is how long it takes for the network to stop routing incoming traffic to an offline client when there’s an online one available. How long will the address likely be unreachable in one of these transition moments, assuming some peer immediately detects that a “tracker” onion address has gone offline and begins hosting it themselves? (And does this question make sense?) Thanks! Holmes

3 4

sigstore for improving verification of downloads?
by axel simon 08 Apr '21

08 Apr '21

Hello all, I've been a Tor user for a long time, have helped a bit with translation at times, and been working on issues related to freedom and the Internet for a while (as part of La Quadrature du Net), but i'm writing today with my work hat on, as a member of the security team at Red Hat's office of the CTO. We recently announced a new project called sigstore [1], which could be summarised as "Let's Encrypt, but for software provenance and code signing". If you want to read other people explain it better than me, i found these two articles did a good job: - https://www.darkreading.com/application-security/linux-foundation-debuts-si… - https://www.zdnet.com/article/linux-foundation-announces-new-open-source-so… In any case, the idea is to provide a public good service, heavily inspired by Let's Encrypt, that lets developpers sign packages, containers, code artifacts in general, and lets user verify them in a simple way. It's still early days, but the aim is to make it a lot easier to verify the integrity of software, and to do better and easier than "here's a binary, here's an .asc detached PGP signature, here's a page that says that 0xBLA is our public key", which as we know is a procedure most users simply don't follow. To avoid the pains of key management (and the nasty targets keys quickly become), sigstore uses ephemeral signing keys (which don't ever touch the disk), publishes the signature in a first transparency log, and discards the key after signature. The other part of the system, which connects a signing key to an entity, is based on issuing a certificate to the signer which contains their email address and their pubkey, if they can prove control of the email address using OpenID Connect. This certificate is then stored in a second transpararency log, which provides a second root of trust, directly inspired by the Certificate Transparency project [2]. Using both transparency logs (signatures and certificates), one can then verify that a binary download is the expected one, and that is was signed by someone who controls an email address. Tools are being built to do this automatically, and in a repeatable way. The idea is also to make it easy for developers to monitor the certificate transparency log for their email, which could alert them to untowards actions, if a new certificate pops up for something they never signed. The OpenID Connect part is designed to allow for both large ID providers (like Github or Google) and bring-your-own. As i was saying, it's still early days, but it's coming along nicely and in my mind, Tor (and TAILS) are projects that would very much benefit from sigstore, hence this email. Work is currently under way with the Ruby and WebAssembly communities to help them use sigstore to sign their stuff, and more generally the project has been well received so far. The whole system is, of course, free and open source and i might add, welcomes new contributors. [3] We also have a chat, if anyone is into that kind of thing. [4] Interested in your thoughts, critiques etc. Thanks and hope this is helpful! axel 1. Jointly with Google and Purdue University, https://sigstore.dev 2. https://certificate.transparency.dev/ 3. https://github.com/sigstore 4. https://join.slack.com/t/sigstore/shared_invite/zt-mhs55zh0-XmY3bcfWn4XEyMq… -- axel simon axel(a)redhat.com // axel+tor(a)axelsimon.net

1 0

My tool I made which makes running relays on Windows very simple.
by Keifer Bly 28 Mar '21

28 Mar '21

Hi all, So this is a tool I developed for tor which makes running relays on Windows very simple. https://www.youtube.com/watch?v=Vpk6yvUWQqU Features: Example torrc file which can be configured as wanted. Automatically checks if tor is running the newest version on startup, if not updates to newest version. One button configuration to configure relay to start when Windows starts. Generates a tor log file which can tell tor messages. Drawbacks: Only supports vanilla bridges. Configures Windows Defender Firewall automatically to allow tor traffic, but other firewalls will need to be manually configured. Cheers. --Keifer

1 0

A new idea for email encryption on tor
by Keifer Bly 28 Mar '21

28 Mar '21

Hi there, So I have a new email encryption system which requires that the user has the specific key file generated for a message rather than the password, specifically this software generates a unique key file for a specific message every time a message is created. The user then enters the date and time the message was created. Without the original key file the message can't be opened; https://www.youtube.com/watch?v=R0W7OVdNrOA Here is a video showing the software. I've built it for Windows and Mac OS. I was wondering if this could be implemented in tor. I think it would be an interesting idea for a tor based email system to make the messages unrecoverable after use. OS: Windows, Mac OS What do you think? --Keifer

4 5

Proposal 329: Traffic Splitting (Conflux)
by Mike Perry 26 Mar '21

26 Mar '21

I'm pleased to present for your enjoyment, excitement, and enlightenment: Tor Proposal 329: Traffic Splitting! I've included it inline below. The canonical version for merge exists in a gitlab MR: https://gitlab.torproject.org/tpo/core/torspec/-/merge_requests/34 Please merge that one, as it also has a commit to add a much-deserved Acknowledgement section to Proposal 324, too. Feel free to respond on-thread, though! ================================================================== Filename: 329-traffic-splitting.txt Title: Overcoming Tor's Bottlenecks with Traffic Splitting Author: David Goulet, Mike Perry Created: 2020-11-25 Status: Draft 0. Status This proposal describes the Conflux [CONFLUX] system developed by Mashael AlSabah, Kevin Bauer, Tariq Elahi, and Ian Goldberg. It aims at improving Tor client network performance by dynamically splitting traffic between two circuits. 1. Overview 1.1. Multipath TCP Design Space In order to understand our improvements to Conflux, it is important to properly conceptualize what is involved in the design of multipath algorithms in general. The design space is broken into two orthogonal parts: congestion control algorithms that apply to each path, and traffic scheduling algorithms that decide when to send packets to send on each path. MPTCP specifies 'coupled' congestion control (see [COUPLED]). Coupled congestion control updates single-path congestion control algorithms to account for shared bottlenecks between the paths, so that the combined congestion control algorithms do not overwhelm any bottlenecks that happen to be shared between the multiple paths. Various ways of accomplishing this have been proposed and implemented in the Linux kernel. Because Tor's congestion control only concerns itself with bottnecks in Tor relay queues, and not with any other bottlenecks (such as intermediate Internet routers), we can avoid this complexity merely by specifying that any paths that are constructed should not share any relays. In this way, we can proceed to use the exact same congestion control as specified in Proposal 324, for each path. For this reason, this proposal will focus on the traffic scheduling algorithms, rather than coupling. We propose three candidate algorithms that have been studied in the literature, and will compare their performance using simulation and consensus parameters. 1.2. Divergence from the initial Conflux design The initial [CONFLUX] paper doesn't provide any indications on how to handle the size of out-of-order cell queue, which we consider a potential dangerous memory DoS vector (see [MEMORY_DOS]). It also used RTT as the sole heuristic for selecting which circuit to send on, which may vary depending on the geographical locations of the participant relays, without considering their actual available circuit capacity (which will be available to us via Proposal 324). Additionally, since the publication of [CONFLUX], more modern packet scheduling algorithms have been developed, which aim to reduce out-of-order queue size. We propose mitigations for these issues using modern scheduling algorithms, as well as implementations options for avoiding the out-of-order queue at Exit relays. Additionally, we consider resumption, side channel, and traffic analysis risks and benefits in [RESUMPTION], [SIDE_CHANNELS] and [TRAFFIC_ANALYSIS]. 2. Design The following section describes the Conflux design. Each sub-section is a building block to the multipath design that Conflux proposes. The circuit construction is as follow: Primary Circuit (lower RTT) +-------+ +--------+ |Guard 1|----->|Middle 1|----------+ +---^---+ +--------+ | +-----+ | +--v---+ | OP +------+ | Exit |--> ... +-----+ | +--^---+ +---v---+ +--------+ | |Guard 2|----->|Middle 2|----------+ +-------+ +--------+ Secondary Circuit (higher RTT) Both circuits are built using current Tor path selection, however they SHOULD NOT share the same Guard relay, or middle relay. By avoiding using the same relays in these positions in the path, we ensure additional path capacity, and eliminate the need to use more complicated 'coupled' congestion control algorithms from the MPTCP literature[COUPLED]. This both simplifies design, and improves performance. Then, the OP needs to link the two circuits together, as described in [LINKING_CIRCUITS], [LINKING_EXIT], and [LINKING_SERVICE]. For ease of explanation, the primary circuit is the circuit with lower RTT, and the secondary circuit is the circuit with higher RTT. Initial RTT is measured during circuit linking, as described in [LINKING_CIRCUITS]. RTT is continually measured using SENDME timing, as in Proposal 324. This means that during use, the primary circuit and secondary circuit may switch roles, depending on unrelated network congestion caused by other Tor clients. We also support linking onion service circuits together. In this case, only two rendezvous circuits are linked. Each of these RP circuits will be constructed separately, and then linked. However, the same path constraints apply to each half of the circuits (no shared relays between the legs). Should, by chance, the service and the client sides end up sharing some relays, this is not catastrophic. Multipath TCP researchers we have consulted believe Tor's congestion control from Proposal 324 to be sufficient in this rare case. Only two circuits SHOULD be linked together. However, implementations SHOULD make it easy for researchers to *test* more than two paths, as this has been shown to assist in traffic analysis resistance[WTF_SPLIT]. At minimum, this means not hardcoding only two circuits in the implementation. If the number of circuits exceeds the current number of guard relays, guard relays MAY be re-used, but implementations SHOULD use the same number of Guards as paths. Linked circuits MUST NOT be extended further once linked (ie: 'cannibalization' is not supported). 2.1. Advertising support for conflux We propose a new protocol version in order to advertise support for circuit linking on the relay side: "Relay=4" -- Relay supports an 2 byte sequence number in a RELAY cell header used for multipath circuit which are linked with the new RELAY_CIRCUIT_LINK relay cell command. XXX: Advertise this in onion service descriptor. XXX: Onion service descriptor can advertise more than two circuits? The next section describes how the circuits are linked together. 2.2. Linking circuits [LINKING_CIRCUITS] To link circuits, we propose new relay commands that are sent on both circuits, as well as a response to confirm the join, and an ack of this response. These commands create a 3way handshake, which allows each endpoint to measure the initial RTT of each leg upon link, without needing to wait for any data. All three stages of this handshake are sent on *each* circuit leg to be linked. To save round trips, these cells SHOULD be combined with the initial RELAY_BEGIN cell on the faster circuit leg, using Proposal 325. See [LINKING_EXIT] and [LINKING_SERVICE] for more details on setup in each case. There are other ways to do this linking that we have considered, but they seem not to be significantly better than this method, especially since we can use Proposal 325 to eliminate the RTT cost of this setup before sending data. For those other ideas, see [ALTERNATIVE_LINKING] and [ALTERNATIVE_RTT], in the appendix. The first two parts of the handshake establish the link, and enable resumption: 16 -- RELAY_CIRCUIT_LINK Sent from the OP to the exit/service in order to link circuits together at the end point. 17 -- RELAY_CIRCUIT_LINKED Sent from the exit/service to the OP, to confirm the circuits were linked. These cells have the following contents: VERSION [1 byte] PAYLOAD [variable, up to end of relay payload] The VERSION tells us which circuit linking mechanism to use. At this point in time, only 0x01 is recognized and is the one described by the Conflux design. For version 0x01, the PAYLOAD contains: NONCE [32 bytes] LAST_SEQNO_SENT [8 bytes] LAST_SEQNO_RECV [8 bytes] XXX: Should we let endpoints specify their preferred [SCHEDULING] alg here, to override consensus params? This has benefits: eg low-memory mobile clients can ask for an alg that is better for their reorder queues. But it also has complexity risk, if the other endpoint does not want to support it, because of its own memory issues. The NONCE contains a random 256-bit secret, used to associate the two circuits together. The nonce must not be shared outside of the circuit transmission, or data may be injected into TCP streams. This means it MUST NOT be logged to disk. The two sequence number fields are 0 upon initial link, but non-zero in the case of a resumption attempt (See [RESUMPTION]). If either circuit does not receive a RELAY_CIRCUIT_LINKED response, both circuits MUST be closed. The third stage of the handshake exists to help the exit/service measure initial RTT, for use in [SCHEDULING]: 18 -- RELAY_CIRCUIT_LINKED_RTT_ACK Sent from the OP to the exit/service, to provide initial RTT measurement for the exit/service. For timeout of the handshake, clients should use the normal SOCKS/stream timeout already in use for RELAY_BEGIN. These three relay commands (RELAY_CIRCUIT_LINK, RELAY_CIRCUIT_LINKED, and RELAY_CIRCUIT_LINKED_ACK) are send on *each* leg, to allow each endpoint to measure the initial RTT of each leg. 2.2. Linking Circuits from OP to Exit [LINKING_EXIT] To link exit circuits, two circuits to the same exit are built. The client records the circuit build time of each. If the circuits are being built on-demand, for immediate use, the circuit with the lower build time SHOULD use Proposal 325 to append its first RELAY cell to the RELAY_COMMAND_LINK, on the circuit with the lower circuit build time. The exit MUST respond on this same leg. After that, actual RTT measurements MUST be used to determine future transmissions, as specified in [SCHEDULING]. The RTT times between RELAY_COMMAND_LINK and RELAY_COMMAND_LINKED are measured by the client, to determine each circuit RTT to determine primary vs secondary circuit use, and for packet scheduling. Similarly, the exit measures the RTT times between RELAY_COMMAND_LINKED and RELAY_COMMAND_LINKED_ACK, for the same purpose. 2.3. Linking circuits to an onion service [LINKING_SERVICE] For onion services, we will only concern ourselves with linking rendezvous circuits. To join rendezvous circuits, clients make two introduce requests to a service's intropoint, causing it to create two rendezvous circuits, to meet the client at two separate rendezvous points. These introduce requests MUST be sent to the same intropoint (due to potential use of onionbalance), and SHOULD be sent back-to-back on the same intro circuit. They MAY be combined with Proposal 325. The first rendezvous circuit to get joined SHOULD use Proposal 325 to append the RELAY_BEGIN command, and the service MUST answer on this circuit, until RTT can be measured. Once both circuits are linked and RTT is measured, packet scheduling should be used, as per [SCHEDULING]. 2.4. Congestion Control Application [CONGESTION_CONTROL] The SENDMEs for congestion control are performed per-leg. As data arrives, regardless of its ordering, it is counted towards SENDME delivery. In this way, 'cwnd - package_window' of each leg always reflects the available data to send on each leg. This is important for [SCHEDULING]. The Congestion control Stream XON/XOFF can be sent on either leg, and applies to the stream's transmission on both legs. 2.5. Sequencing [SEQUENCING] With multiple paths for data, the problem of data re-ordering appears. In other words, cells can arrive out of order from the two circuits where cell N + 1 arrives before the cell N. Handling this reordering operates after congestion control for each circuit leg, but before relay cell command processing or stream data delivery. For the receiver to be able to reorder the receiving cells, a sequencing scheme needs to be implemented. However, because Tor does not drop or reorder packets inside of a circuit, this sequence number can be very small. It only has to signal that a cell comes after those arriving on another circuit. To achieve this, we add a small sequence number to the common relay header for all relay cells on linked circuits. This sequence number is meant to signal the number of cells sent on the *other* leg, so that each endpoint knows how many cells are still in-flight on another leg. It is different from the absolute sequence number used in [LINKING_CIRCUITS] and [RESUMPTION], but can be derived from that number, using relative arithmetic. Relay command [1 byte] Recognized [2 bytes] StreamID [2 bytes] Digest [4 bytes] Length [2 bytes] > LongSeq [1 bit] # If this bit is set, use 31 bits for Seq > Sequencing [7 or 31 bits] Data [Remainder] The sequence number is only set for the first cell after the endpoint switches legs. In this case, LongSeq is set to 1, and the Sequencing field is 31 more bits. Otherwise it is a 1 byte 0 value. These fields MUST be present on ALL end-to-end relay cells on each leg that come from the endpoint, following a RELAY_CIRCUIT_LINK command. They are absent on 'leaky pipe' RELAY_COMMAND_DROP and RELAY_COMMAND_PADDING_NEGOTIATED cells that come from middle relays, as opposed to the endpoint, to support padding. When an endpoint switches legs, on the first cell in a new leg, LongSeq is set to 1, and the following 31 bits represent the *total* number of cells sent on the *other* leg, before the switch. The receiver must wait for that number of cells to arrive from the previous leg before delivering that cell. XXX: In the rare event that we send more than 2^31 cells (~1TB) on a single leg, do we force a switch of legs, or expand the field further? An alternative method of sequencing, that assumes that the endpoint knows when it is going to switch, the cell before it switches, is specified in [ALTERNATIVE_SEQUENCING]. Note that that method requires only 1 byte for sequence number and switch signaling, but requires that the sender know that it is planning to switch, the cell before it switches. (This is possible with [BLEST_TOR], but [LOWRTT_TOR] can switch based on RTT change, so it may be one cell late in that case). 2.6. Resumption [RESUMPTION] In the event that a circuit leg is destroyed, they MAY be resumed. Resumption is achieved by re-using the NONCE and method to the same endpoint (either [LINKING_EXIT] or [LINKING_SERVICE]). The resumed path need not use the same middle and guard relays, but should not share any relays with any existing legs(s). To provide resumption, endpoints store an absolute 64bit cell counter of the last cell they have sent on a conflux pair (their LAST_SEQNO_SENT), as well the last sequence number they have delivered in-order to edge connections corresponding to a conflux pair (their LAST_SEQNO_RECV). Additionally, endpoints MAY store the entire contents of unacked inflight cells (ie the 'package_window' from proposal 324), for each leg, along with information corresponding to those cells' absolute sequence numbers. These 64 bit absolute counters can wrap without issue, as congestion windows will never grow to 2^64 cells until well past the Singularity. However, it is possible that extremely long, bulk circuits could exceed 2^64 total sent or received cells, so endpoints SHOULD handle wrapped sequence numbers for purposes of computing retransmit information. (But even this case is unlikely to happen within the next decade or so). Upon resumption, the LAST_SEQNO_SENT and LAST_SEQNO_RECV fields are used to convey the sequence numbers of the last cell the relay sent and received on that leg. The other endpoint can use these sequence numbers to determine if it received the in-flight data or not, or sent more data since that point, up to and including this absolute sequence number. If LAST_SEQNO_SENT has not been received, the endpoint MAY transmit the missing data, if it still has it buffered. Because both endpoints get information about the other side's absolute SENT sequence number, they will know exactly how many re-transmitted packets to expect, should the circuit stay open. Re-transmitters should not re-increment their absolute sent fields while re-transmitting. If it does not have this missing data due to memory pressure, that endpoint should destroy *both* legs, as this represents unrecoverable data loss. Otherwise, the new circuit can be re-joined, and its RTT can be compared to the remaining circuit to determine if the new leg is primary or secondary. It is even possible to resume conflux circuits where both legs have been collapsed using this scheme, if endpoints continue to buffer their unacked package_window data for some time after this close. However, see [TRAFFIC_ANALYSIS] for more details on the full scope of this issue. If endpoints are buffering package_window data, such data should be given priority to be freed in any oomkiller invocation. See [MEMORY_DOS] for more oomkiller information. 3. Traffic Scheduling [SCHEDULING] In order to load balance the traffic between the two circuits, the original conflux paper used only RTT. However, with Proposal 324, we will have accurate information on the instantaneous available bandwidth of each circuit leg, as 'cwnd - package_window' (see Section 3 of Proposal 324). Some additional RTT optimizations are also useful, to improve responsiveness and minimize out-of-order queue sizes. We specify two traffic schedulers from the multipath literature and adapt them to Tor: [LOWRTT_TOR] and [BLEST_TOR]. [LOWRTT_TOR] also has three variants, with different trade offs. However, see the [TRAFFIC_ANALYSIS] sections of this proposal for important details on how this selection can be changed, to reduce website traffic fingerprinting. 3.1. LowRTT Scheduling [LOWRTT_TOR] This scheduling algorithm is based on the original [CONFLUX] paper, with ideas from [MPTCP]'s minRTT/LowRTT scheduler. In this algorithm, endpoints send cells on the circuit with lower RTT (primary circuit). This continues while the congestion window on the circuit has available room: ie whenever cwnd - package_window > 0. Whenever the primary circuit's congestion window becomes full, the secondary circuit is used. We stop reading on the send window source (edge connection) when both congestion windows become full. In this way, unlike original conflux, we switch to the secondary circuit without causing congestion on the primary circuit. This improves both load times, and overall throughput. This behavior matches minRTT from [MPTCP], sometimes called LowRTT. It may be better to stop reading on the edge connection when the primary congestion window becomes full, rather than switch to the secondary circuit as soon as the primary congestion window becomes full. (Ie: only switch if the RTTs themselves change which circuit is primary). This is what was done in the original Conflux paper. This behavior effectively causes us to optimize for responsiveness and congestion avoidance, rather than throughput. For evaluation, we should control this switching behavior with a consensus parameter (see [CONSENSUS_PARAMETERS]). Because of potential side channel risk (see [SIDE_CHANNELS]), a third variant of this algorithm, where the primary circuit is chosen during the [LINKING_CIRCUITS] handshake and never changed, should also be possible to control via consensus parameter. 3.2. BLEST Scheduling [BLEST_TOR] [BLEST] attempts to predict the availability of the primary circuit, and use this information to reorder transmitted data, to minimize head-of-line blocking in the recipient (and thus minimize out-of-order queues there). BLEST_TOR uses the primary circuit until the congestion window is full. Then, it uses the relative RTT times of the two circuits to calculate how much data can be sent on the secondary circuit faster than if we just waited for the primary circuit to become available. This is achieved by computing two variables at the sender: rtts = secondary.currRTT / primary.currRTT primary_limit = primary.cwnd + (rtts-1)/2)*rtts Note: This (rtts-1)/2 factor represents anticipated congestion window growth over this period.. it may be different for Tor, depending on CC alg. If primary_limit < secondary.cwnd - (secondary.package_window + 1), then there is enough space on the secondary circuit to send data faster than we could than waiting for the primary circuit. XXX: Note that BLEST uses total_send_window where we use secondary.cwnd in this check. total_send_window is min(recv_win, CWND). But since Tor does not use receive windows and intead uses stream XON/XOFF, we only use CWND. There is some concern this may alter BLEST's buffer minimization properties, but since receive window should only matter if the application is slower than Tor, and XON/XOFF should cover that case, hopefully this is fine. Otherwise, if the primary_limit condition is not hit, cease reading on source edge connections until SENDME acks come back. Here is the pseudocode for this: while source.has_data_to_send(): if primary.cwnd > primary.package_window: primary.send(source.get_packet()) continue rtts = secondary.currRTT / primary.currRTT primary_limit = (primary.cwnd + (rtts-1)/2)*rtts if primary_limit < secondary.cwnd - (secondary.package_window+1): secondary.send(source.get_packet()) else: break # done for now, wait for SENDME to free up CWND and restart Note that BLEST also has a parameter lambda that is updated whenever HoL blocking occurs. Because it is expensive and takes significant time to signal this over Tor, we omit this. XXX: See [REORDER_SIGNALING] section if we want this lambda feedback. 3.3. Reorder queue signaling [REORDER_SIGNALING] Reordering should be fairly simple task. By following using the sequence number field in [SEQUENCING], endpoints can know how many cells are still in flight on the other leg. To reorder them properly, a buffer of out of order cells needs to be kept. On the Exit side, this can quickly become overwhelming considering ten of thousands of possible circuits can be held open leading to gigabytes of memory being used. There is a clear potential memory DoS vector which means that a tor implementation should be able to limit the size of those queues. Luckily, [BLEST_TOR] and the form of [LOWRTT_TOR] that only uses the primary circuit will minimize or eliminate this out-of-order buffer. XXX: The remainder of this section may be over-complicating things... We only need these concepts if we want to use BLEST's lambda feedback. The default for this queue size is governed by the 'cflx_reorder_client' and 'cflx_reorder_srv' consensus parameters (see [CONSENSUS_PARAMS]). 'cflx_reorder_srv' applies to Exits and onion services. Both parameters can be overridden by Torrc, to larger or smaller than the consensus parameter. (Low memory clients may want to lower it; SecureDrop onion services or other high-upload services may want to raise it). When the reorder queue hits this size, a RELAY_CONFLUX_XOFF is sent down the circuit leg that has data waiting in the queue and use of that leg must cease, until it drains to half of this value, at which point an RELAY_CONFLUX_XON is sent. Note that this is different than the stream XON/XOFF from Proposal 324. XXX: [BLEST] actually does not cease use of a path in this case, but instead uses this signal to adjust the lambda parameter, which biases traffic away from that leg. 4. Security Considerations 4.1. Memory Denial of Service [MEMORY_DOS] Both reorder queues and retransmit buffers inherently represent a memory denial of service condition. For [RESUMPTION] retransmit buffers, endpoints that support this feature SHOULD free retransmit information as soon as they get close to memory pressure. This prevents resumption while data is in flight, but will not otherwise harm operation. For reorder buffers, adversaries can potentially impact this at any point, but most obviously and most severely from the client position. In particular, clients can lie about sequence numbers, sending cells with sequence numbers such that the next expected sequence number is never sent. They can do this repeatedly on many circuits, to exhaust memory at exits. One option is to only allow actual traffic splitting in the downstream direction, towards clients, and always use the primary circuit for everything in the upstream direction. However, the ability to support conflux from the client to the exit shows promise against traffic analysis (see [WTF_SPLIT]). The other option is to use [BLEST_TOR] from clients to exits, as it has predictable interleaved cell scheduling, and minimizes reorder queues at exits. If the ratios prescribed by that algorithm are not followed within some bounds, the other endpoint can close both circuits, and free the queue memory. This still leaves the possibility that intermediate relays may block a leg, allowing cells to traverse only one leg, thus still accumulating at the reorder queue. Clients can also spoof sequence numbers similarly, to make it appear that they are following [BLEST_TOR], without actually sending any data on one of the legs. To handle either of these cases, when a relay is under memory pressure, the circuit OOM killer SHOULD free and close circuits with the oldest reorder queue data, first. This heuristic was shown to be best during the [SNIPER] attack OOM killer iteration cycle. 4.2. Side Channels [SIDE_CHANNELS] Two potential side channels may be introduced by the use of Conflux: 1. RTT leg-use bias by altering SENDME latency 2. Location info leaks through the use of both leg's latencies For RTT and leg-use bias, Guard relays could delay legs to introduce a pattern into the delivery of cells at the exit relay, by varying the latency of SENDME cells (every 100th cell) to change the distribution of traffic to send information. This attack could be performed in either direction of traffic, to bias traffic load off of a particular Guard. If an adversary controls both Guards, it could in theory send a binary signal more easily, by alternating delays on each. However, this risk weighs against the potential benefits against traffic fingerprinting, as per [WTF_SPLIT]. Additionally, even ignoring cryptographic tagging attacks, this side channel provides significantly lower information over time than inter-packet-delay based side channels that are already available to Guards and routers along the path to the Guard. Tor currently provides no defenses against already existing single-circuit delay-based side channels, though both circuit padding and [BACKLIT] are potential options it could conceivably deploy. The [BACKLIT] paper also has an excellent review of the various methods that have been studied for such single circuit side channels, and the [BACKLIT] style RTT monitoring could be used to protect against these conflux side channels as well. Circuit padding can also help to obscure which cells are SENDMEs, since circuit padding is not counted towards SENDME totals. The second class of side channel is where the Exit relay may be able to use the two legs to further infer more information about client location. See [LATENCY_LEAK] for more details. It is unclear at this time how much more severe this is for two paths than just one. We should preserve the ability to disable conflux to and from Exit relays, should these side channels prove more severe, or should it prove possible to mitigate single-circuit side channels, but not conflux side channels. In all cases, all of these side channels appear less severe for onion service traffic, due to the higher path variability due to relay selection, as well as the end-to-end nature of conflux in that case. This indicates that our ability to enable/disable conflux for services should be separate from Exits. 4.3. Traffic analysis [TRAFFIC_ANALYSIS] Even though conflux shows benefits against traffic analysis in [WTF_SPLIT], these gains may be moot if the adversary is able to perform packet counting and timing analysis at guards to guess which specific circuits are linked. In particular, the 3 way handshake in [LINKING_CIRCUITS] may be quite noticeable. As one countermeasure, it may be possible to eliminate the third leg (RELAY_CIRCUIT_LINKED_ACK) by computing the exit/service RTT via measuring the time between CREATED/REND_JOINED and RELAY_CIRCUIT_LINK, but this will introduce cross-component complexity into Tor's protocol that could quickly become unwieldy and fragile. Additionally, the conflux handshake may make onion services stand out more, regardless of the number of stages in the handshake. For this reason, it may be more wise to simply address these issues with circuit padding machines during circuit setup (see padding-spec.txt). Additional traffic analysis considerations arise when combining conflux with padding, for purposes of mitigating traffic fingerprinting. For this, it seems wise to treat the packet schedulers as another piece of a combined optimization problem in tandem with optimizing padding machines, perhaps introducing randomness or fudge factors their scheduling, as a parameterized distribution. For details, see https://github.com/torproject/tor/blob/master/doc/HACKING/CircuitPaddingDev… Finally, conflux may exacerbate forms of confirmation-based traffic analysis that close circuits to determine concretely if they were in use, since closing either leg might cause resumption to fail. TCP RST injection can perform this attack on the side, without surveillance capability. [RESUMPTION] with buffering of the inflight unacked package_window data, for retransmit, is a partial mitigation, if endpoints buffer this data for retransmission for a brief time even if both legs close. This seems more feasible for onion services, which are more vulnerable to this attack. However, if the adversary controls the client, they will notice the resumption re-link, and still obtain confirmation that way. It seems the only way to fully mitigate these kinds of attacks is with the Snowflake pluggable transport, which provides its own resumption and retransmit behavior. Additionally, Snowflake's use of UDP DTLS also protects against TCP RST injection, which we suspect to be the main vector for such attacks. In the future, a DTLS or QUIC transport for Tor such as masque could provide similar RST injection resistance, and resumption at Guard/Bridge nodes, as well. 5. System Interactions - congestion control - EWMA and KIST - CBT and number of guards - Onion service circ obfuscation - Future UDP (may increase need for UDP to buffer before dropping) - Padding (no sequence numbers on padding cells, as per [SEQUENCING]) - Also, any padding machines may need re-tuning - No 'cannibalization' of linked circuits 6. Consensus and Torrc Parameters [CONSENSUS] - conflux_circs - Number of conflux circuits - conflux_sched_exits, conflux_sched_clients, conflux_sched_service - Three forms of LOWRTT_TOR, and BLEST_TOR - ConfluxOnionService - ConfluxOnionCircs 7. Tuning Experiments [EXPERIMENTS] - conflux_sched & conflux_exits - Exit reorder queue size - Responsiveness vs throughput tradeoff? - Congestion control - EWMA and KIST - num guards & conflux_circs Appended A [ALTERNATIVES] A.1 BEGIN/END sequencing [ALTERNATIVE_SEQUENCING] In this method of signaling, we increment the sequence number by 1 only when we switch legs, and use BEGIN/END "bookends" to know that all data on a leg has been received. To achieve this, we add a small sequence number to the common relay header for all relay cells on linked circuits, as well as a field to signal the beginning of a sequence, intermediate data, and the end of a sequence. Relay command [1 byte] Recognized [2 bytes] StreamID [2 bytes] Digest [4 bytes] Length [2 bytes] > Switching [2 bits] # 01 = BEGIN, 00 = CONTINUE, 10 = END > Sequencing [6 bits] Data [PAYLOAD_LEN - 12 - Length bytes] These fields MUST be present on ALL end-to-end relay cells on each leg that come from the endpoint, following a RELAY_CIRCUIT_LINK command. They are absent on 'leaky pipe' RELAY_COMMAND_DROP and RELAY_COMMAND_PADDING_NEGOTIATED cells that come from middle relays, as opposed to the endpoint, to support padding. Sequence numbers are incremented by one when an endpoint switches legs to transmit a cell. This number will wrap; implementations should treat 0 as the next sequence after 2^6-1. Because we do not expect to support significantly more than 2 legs, and much fewer than 63, this is not an issue. The first cell on a new circuit MUST use the BEGIN code for switching. Cells are delivered from that circuit until an END switching signal is received, even if cells arrive first on another circuit with the next sequence number before and END switching field. Recipients MUST only deliver cells with a BEGIN, if their Sequencing number is one more than the last END. A.2 Alternative Link Handshake [ALTERNATIVE_LINKING] The circuit linking in [LINKING_CIRCUITS] could be done as encrypted ntor onionskin extension fields, similar to those used by v3 onions. This approach has at least four problems: i). For onion services, since onionskins traverse the intro circuit and return on the rend circuit, this handshake cannot measure RTT there. ii). Since these onionskins are larger, and have no PFS, an adversary at the middle relay knows that the onionskin is for linking, and can potentially try to obtain the onionskin key for attacks on the link. iii). It makes linking circuits more fragile, since they could timeout due to CBT, or other issues during construction. iv). The overhead in processing this onionskin in onionskin queues adds additional time for linking, even in the Exit case, making that RTT potentially noisy. Additionally, it is not clear that this approach actually saves us anything in terms of setup time, because we can optimize away the linking phase using Proposal 325, to combine initial RELAY_BEGIN cells with RELAY_CIRCUIT_LINK. A.3. Alternative RTT measurement [ALTERNATIVE_RTT] Instead of measuring RTTs during [LINKING_CIRCUITS], we could create PING/PONG cells, whose sole purpose is to allow endpoints to measure RTT. This was rejected for several reasons. First, during circuit use, we already have SENDMEs to measure RTT. Every 100 cells (or 'circwindow_inc' from Proposal 324), we are able to re-measure RTT based on the time between that Nth cell and the SENDME ack. So we only need PING/PONG to measure initial circuit RTT. If we were able to use onionskins, as per [ALTERNATIVE_LINKING] above, we might be able to specify a PING/PONG/PING handshake solely for measuring initial RTT, especially for onion service circuits. The reason for not making a dedicated PING/PONG for this purpose is that it is context-free. Even if we were able to use onionskins for linking and resumption, to avoid additional data in handshake that just measures RTT, we would have to enforce that this PING/PONG/PING only follows the exact form needed by this proposal, at the expected time, and at no other points. If we do not enforce this specific use of PING/PONG/PING, it becomes another potential side channel, for use in attacks such as [DROPMARK]. In general, Tor is planning to remove current forms of context-free and semantic-free cells from its protocol: https://gitlab.torproject.org/tpo/core/torspec/-/issues/39 We should not add more. Appendix B: Acknowledgments Thanks to Per Hurtig for helping us with the framing of the MPTCP problem space. Thanks to Simone Ferlin for clarifications on the [BLEST] paper, and for pointing us at the Linux kernel implementation. Extreme thanks goes again to Toke Høiland-Jørgensen, who helped immensely towards our understanding of how the BLEST condition relates to edge connection pushback, and for clearing up many other misconceptions we had. Finally, thanks to Mashael AlSabah, Kevin Bauer, Tariq Elahi, and Ian Goldberg, for the original [CONFLUX] paper! References: [CONFLUX] https://freehaven.net/anonbib/papers/pets2013/paper_65.pdf [BLEST] https://olivier.mehani.name/publications/2016ferlin_blest_blocking_estimati… https://opus.lib.uts.edu.au/bitstream/10453/140571/2/08636963.pdf https://github.com/multipath-tcp/mptcp/blob/mptcp_v0.95/net/mptcp/mptcp_ble… [WTF_SPLIT] https://www.comsys.rwth-aachen.de/fileadmin/papers/2020/2020-delacadena-tra… [COUPLED] https://datatracker.ietf.org/doc/html/rfc6356 https://www.researchgate.net/profile/Xiaoming_Fu2/publication/230888515_Del… http://staff.ustc.edu.cn/~kpxue/paper/ToN-wwj-2020.04.pdf https://www.thinkmind.org/articles/icn_2019_2_10_30024.pdf https://arxiv.org/pdf/1308.3119.pdf [BACKLIT] https://www.freehaven.net/anonbib/cache/acsac11-backlit.pdf [LATENCY_LEAK] https://www.freehaven.net/anonbib/cache/ccs07-latency-leak.pdf https://www.robgjansen.com/publications/howlow-pets2013.pdf [SNIPER] https://www.freehaven.net/anonbib/cache/sniper14.pdf [DROPMARK] https://www.freehaven.net/anonbib/cache/sniper14.pdf -- Mike Perry

1 0

staking donations
by Jeff Burdges 25 Mar '21

25 Mar '21

I realize this would be the wrong part of the Tor project to which to suggest this, but I know the people on this list and I do not know the people elsewhere in Tor, and there is some small technical content here, so.. There are now a bunch of proof-of-stake cybercoins aka crypto-currencies, like polkadot by my employer, cosmos, cardano, etc. As a rule, these have the property that people who own the currency for one reason or another can lock their currency to help deSybil some special nodes, usually called validators. This earns them some rewards because doing so usually makes them liable for misbehavior of the validator. This is very different from bitcoin where five guys in China and one guy in Island take all the rewards, and those six guys spend a lot of real money doing so. Now quite a lot of people are claiming these reward, and the real work they are doing is running one server, or even merely saying “I know that dude and he seems okay”. This means a lot of people suddenly have an income stream on which they need to pay taxes, but for which the taxes are complex. At least a few of these people do not yet stake because they do not yet know how to handle the taxes, like maybe they need time to set up a company or whatever. At least a few of these should’ve a somewhat flexible key infrastructure like I had us do in polkadot, and in particular users can simply point their rewards at another address besides the one from which they stake. If you’re a non-profit that can avoid the tax complexities, then it’d be a good time to accept donations in these new crypto currencies, because aside from regular donation some people might just skip thinking about their own taxes for a while by point their rewards at someone like Tor who’d spend the money usefully.. at least temporarily. I realize there might be other complexities of course, but if this were interesting then I could likely convince someone around here to implement some partial rewards division thing, which might enable people to contribute longer term. Best, Jeff

1 0

Please reconsider Issue #2667 (tor over tor is much needed)
by maketorgreatagain 23 Mar '21

23 Mar '21

Good day, We am making this request to our bellowed Tor Project developers and relay operators to reconsider issue https://gitlab.torproject.org/tpo/core/tor/-/issues/2667. Tor over tor scenario is not recommended by Tor project but We are forced to use such setup to hide our operations from the powerful adversary which would in case we use bridge between our two tor path most likely possible de-anonymize us and put our life in dangerous. Tor is making our work possible and helping collaborate without restrictions, please let's reconsider this issue one more time. We are running number of relay and we considered not applying latest update to help us at least work with our own relay but adversary observes big part of network and will most likely identify us when 70% of network start dropping tor over tor connections. Tor over tor scenario does not amplify attack power within tor network, the strength of any request is losing it's power right after first hop, but for many people it provides necessary and much required privacy. We do highly sensitive work in research journalism across the globe and only way we found so far not be de-anonymized was tor over tor scenario, probably for reason that two circuits are dynamic and it's very hard for adversary to track that down properly due to nature of tor network. Understandable that you most of time support regular Tor Browser usage and 3 hop circuits but believe us there are situations where our scenario is really necessary. We have collected donations of around 21000 USD in XMR so far(we know it's not much), which we can either donate to Tor project to help fix this issue or otherwise fund relay operators to run not-up-to-date relays just to help us operate under this powerful adversary. The second is worse solution as it would make network more vulnerable, or at least allow relay operators to enable or disable that option and don't make it mandatory. Privacy for the win! Much love for Tor project and you relay operators Best regards

1 0

Circuit Creation Madness: Anyone else still experiencing (extremely) excessive clients / (possibly) modified relays creating millions upon millions of circuits?
by William Kane 22 Mar '21

22 Mar '21

@tor-relays: Sorry for being quite noisy recently but I really need to know how many people are suffering from the same madness I am encountering right now. Quick excerpt from the log: ... Mar 22 09:48:10 <hostname_redacted> tor[pid_redacted]: Mar 22 09:48:10.000 [warn] Your computer is too slow to handle this many circuit creation requests! Please consider using the MaxAdvertisedBandwidth config option or choosing a more restricted exit policy. [12420 similar message(s) suppressed in last 120 seconds] Mar 22 09:49:10 <hostname_redacted> tor[pid_redacted]: Mar 22 09:49:10.000 [warn] Your computer is too slow to handle this many circuit creation requests! Please consider using the MaxAdvertisedBandwidth config option or choosing a more restricted exit policy. [31764 similar message(s) suppressed in last 60 seconds] Mar 22 09:50:10 <hostname_redacted> tor[pid_redacted]: Mar 22 09:50:10.000 [warn] Your computer is too slow to handle this many circuit creation requests! Please consider using the MaxAdvertisedBandwidth config option or choosing a more restricted exit policy. [104748 similar message(s) suppressed in last 60 seconds] Mar 22 09:51:10 <hostname_redacted> tor[pid_redacted]: Mar 22 09:51:10.000 [warn] Your computer is too slow to handle this many circuit creation requests! Please consider using the MaxAdvertisedBandwidth config option or choosing a more restricted exit policy. [364165 similar message(s) suppressed in last 60 seconds] Mar 22 09:52:10 <hostname_redacted> tor[pid_redacted]: Mar 22 09:52:10.000 [warn] Your computer is too slow to handle this many circuit creation requests! Please consider using the MaxAdvertisedBandwidth config option or choosing a more restricted exit policy. [509474 similar message(s) suppressed in last 60 seconds] Mar 22 09:53:10 <hostname_redacted> tor[pid_redacted]: Mar 22 09:53:10.000 [warn] Your computer is too slow to handle this many circuit creation requests! Please consider using the MaxAdvertisedBandwidth config option or choosing a more restricted exit policy. [241332 similar message(s) suppressed in last 60 seconds] ... This then goes on for a while, stopping at a few million suppressed messages / circuit creation attempts. Sorry, but 1 million circuit creation requests in just 5 minutes, there is no way that this is legitimate behavior we are seeing - this is also what was previously used to get my relay oom-killed but that I have fixed so the legitimate clients hopefully don't suffer too much anymore. If any other relay operators are encountering the same log entries or behavior, please don't hesitate to reply. Added tor-dev(a)lists.torproject.org as a CC as they might want to know about this. @tor-dev: I suspect some kind of denial-of-service attack against onion services or a more targeted attack against singular relays for guard discovery / traffic confirmation attacks. Might be smart to add some code which, if this scenario is triggered, lists offenders by hashes of their signing keys (if relay), or IP addresses (if client). There doesn't seem to be a defense against this, and the new connect() rate-limit added through ticket 40253 also won't handle this as the connection is already ACK'd and established, and a malicious relay with custom source code could do whatever it was programmed to do anyway. - William

1 0