tor-dev May 2018

tor-dev@lists.torproject.org

26 participants
26 discussions

DNS-over-HTTPS (DOH) in Firefox/Torbrowser
by nusenu 01 Jul '20

01 Jul '20

Hi, since Mozilla did tests [0] on DOH [1] in Firefox I was wondering if Torbrowser developers have put any thought into that as well? Note: I'm _not_ suggesting to use DOH in torbrowser I'm just asking because the answer probably matters for exit documentation in the relay guide if clients do DNS themselves over TCP connections instead of relying on the exit (even if torbrowser is not the only tor client). thanks, nusenu [0] https://www.ghacks.net/2018/03/20/firefox-dns-over-https-and-a-worrying-shi… [1] https://datatracker.ietf.org/doc/draft-hoffman-dns-over-https/ -- https://mastodon.social/@nusenu twitter: @nusenu_

4 4

Lets give every circuit its own exit IP?
by nusenu 18 Mar '20

18 Mar '20

The unbearable situation with Google's reCAPTCHA motivated this email (but it is not limited to this specific case). This idea came up when seeing a similar functionality in unbound (which has it for a different reason). Assumption: There are systems that block some tor exit IP addresses (most likely the bigger once), but they are not blocked due to the fact that they are tor exits. It just occurred that the IP got flagged because of "automated / malicious" requests and IP reputation systems. What if every circuit had its "own" IP address at the exit relay to avoid causing collateral damage to all users of the exit if one was bad? (until the exit runs out of IPs and starts to recycle previously used IPs again) The goal is to avoid accumulating a bad "reputation" for the single used exit IP address that affects all tor users of that exit. Instead of doing it on the circuit level you could do it based on time. Change the exit IP every 5 minutes (but do _not_ change the exit IPs for _existing_ circuits even if they live longer than 5 minutes). Yes, no one has that many IPv4 addresses but with the increasing availability of IPv6 at exits and destinations, this could be feasible to a certain extend, depending on how many IPv6 addresses the exit operator has. There are exit operators that have entire /48 IPv6 blocks. problems: - will not solve anything since reputation will shift to netblocks as well (How big of a netblock are you willing to block?) - you can tell two tor users easily apart from each other even if they use the same exit (or more generally: you can tell circuits apart). There might be all kinds of bad implications that I'm not thinking off right now. - check.tpo would no longer be feasible - how can do we still provide the list of exit IPs for easy blocking? Exits could signal their used netblock via their descriptor. What if they don't? (that in turn opens new kinds of attacks where an exit claims to be /0 and the target effectively blocks everything) - more state to track and store at the exit -... some random thoughts, nusenu -- https://mastodon.social/@nusenu twitter: @nusenu_

4 6

UX improvement proposal: Onion auto-redirects using Alt-Svc HTTP header
by George Kadianakis 26 Oct '18

26 Oct '18

UX improvement proposal: Onion auto-redirects using Alt-Svc HTTP header ======================================================================== 1. Motivation: Lots of high-profile websites have onion addresses these days (e.g. Tor , NYT, blockchain, ProPublica). All those websites seem confused on what's the right way to inform their users about their onion addresses. Here are some confusion examples: a) torproject.org does not even advertise their onion address to Tor users (!!!) b) blockchain.info throws an ugly ASCII page to Tor users mentioning their onion address and completely wrecking the UX (loses URL params, etc.) c) ProPublica has a "Browse via Tor" section which redirects to the onion site. Ideally there would be a consistent way for websites to inform their users about their onion counterpart. This would provide the following positives: + Tor users would use onions more often. That's important for user education and user perception, and also to partially dispell the darkweb myth. + Website operators wouldn't have to come up with ad-hoc ways to advertise their onion services, which sometimes results in complete breakage of the user experience (particularly with blockchain) This proposal specifies a simple way forward here that's far from perfect, but can still provide benefits and also improve user-education around onions so that in the future we could employ more advanced techniques. Also see Tor ticket #21952 for more discussion on this: https://trac.torproject.org/projects/tor/ticket/21952 2. Proposal Websites use the Alt-Svc HTTP header to specify their onion counterpart: http://httpwg.org/http-extensions/alt-svc.html The Tor Browser intercepts that header (if any) and auto-redirects the user to the onion site. Tor Browser only does so if the header is served over HTTPS. (That's it.) 3. Improvements 3.1. User education through notifications To minimize the probability of users freaking out about auto-redirects Tor Browser could inform the user that the auto-redirect is happening. This could happen with a small notification bar [*] below the URL bar informing users that "Tor Browser is auto-redirecting you to the secure onion site". The notification bar could also have a question mark button that provides the user with additional information on the merits of onion sites and why they should like them. [*]: like this one: http://www.topdreamweaverextensions.com/UserFiles/Image/firefox-bar.jpg 3.2. Auto-redirects too intrusive? Make them optional. If we think that auto redirects are too intrusive, we should consider making them optional, or letting the website specify the desired behavior. If a website wants to specify an onion address but doesn't like auto-redirects, it could specify that as part of Alt-Svc and we could still inform the user that an onion is available using a notification bar again. 4. Drawbacks This proposal is far from the perfect solution of course. Here are a few reasons why: 4.1. Auto-redirects are scary Novice users or paranoid users might freak out with auto-redirects since it's unexpected. They might think they are under attack or they got hacked. An argument against that is that we are already using HTTPS-everywhere which is basically a redirection layer, and while its redirection technique is simpler, sometimes the derivative URL is not similar to the original URL, and we still don't see people freaking out. I think that's because people trust Tor Browser to do the right thing. Combining this knowledge with section 3.1 might solve this problem. 4.2. No security/performance benefits While we could come up with auto-redirect proposals that provide security and performance benefits, this proposal does not actually provide any of those. As a matter of fact, the security remains the same as connecting to normal websites (since we trust its HTTP headers), and the performance gets worse since we first need to connect to the website, get its headers, and then also connect to the onion. Still _all_ the website approaches mentioned in the "Motivation" section suffer from the above drawbacks, and sysadmins still come up with ad-hoc ways to inform users abou their onions. So this simple proposal will still help those websites and also pave the way forward for future auto-redirect techniques. 4.3. Alt-Svc does not do exactly what we want I read in a blog post [*] that using Alt-Svc header "doesn’t change the URL in the location bar, document.location or any other indication of where the resource is; this is a “layer below” the URL.". IIUC, this is not exactly what we want because users will not notice the onion address, they will not get the user education part of the proposal and their connection will still be slowed down. I think we could perhaps change this in Tor Browser so that it rewrites the onion address to make it clear to people that they are now surfing the onionspace. [*]: https://www.mnot.net/blog/2016/03/09/alt-svc 5. The future As I said this is just a simple proposal to introduce the auto-redirect concept to people, and also to help some sysadmins who are currently coming up with weird ways to inform people about their onions. It's not the best way to do this, but it's definitely one of the simplest ways. In the future we could implement with more advanced auto-redirect proposals like: a) Have a "domains to onions" map into HTTPS-everywhere and have it do the autoredirects for us (performance benefits, and security benefits under many threat models). b) Bake onion addresses into SSL certificates and Let's Encrypt as suggested by comment:42 in #21952. But both of the designs above require non-trivial engineering/policy work and would still confuse people. So I think starting with a simple approach that will educate users and then moving to more advanced designs is a more normative way to go. ====================================================================== Let me know what you think :) (Should this be part of torspec?)

10 25

Proposal 293: Other ways for relays to know when to publish
by Nick Mathewson 17 Jul '18

17 Jul '18

Filename: 293-know-when-to-publish.txt Title: Other ways for relays to know when to publish Author: Nick Mathewson Created: 30-May-2018 Status: Open Target: 0.3.5 1. Motivation In proposal 275, we give reasons for dropping the published-on field from consensus documents, to improve the performance of consensus diffs. We've already changed Tor (as of 0.2.9.11) to allow us to set those fields far in the future -- but unfortunately, there is still one use case that requires them: relays use the published-on field to tell if they are about to fall out of the consensus and need to make new descriptors. Here we propose two alternative mechanisms for relays to know that they should publish descriptors, so we can enact proposal 275 and set the published-on field to some time in the distant future. 2. Mechanism One: The StaleDesc flag Authorities should begin voting aon a new StaleDesc flag. When authorities vote, if the most recent published_on date for a descriptor has over DESC_IS_STALE_INTERVAL in the past, the authorities should vote to give the StaleDesc flag to that relay. If any relay sees that it has the StaleDesc flag, it should upload some time in the first half of the voting interval. (Implementors should take care not to re-upload over and over, though: Relays won't lose the flag until the next voting interval is reached.) (Define DESC_IS_STALE_INTERVAL as equal to FORCE_REGENERATE_DESCRIPTOR_INTERVAL.) 3. Mechanism Two: Uploading more frequently when rejected. Tor relays should remember the last time at which they uploaded a descriptor that was accepted by a majority of dirauths. If this time is more than FAST_RETRY_DESCRIPTOR_INTERVAL in the past, we mark our descriptor as dirty from mark_my_descriptor_dirty_if_too_old(). 4. Implications for proposal 275 Once most relays are running verions that support the features above, and once authorities are generating consensuses with the StaleDesc flag, there will no longer be a need to keep the published time in consensus documents accurate -- we can start setting it to some time in the distant future, per proposal 275.

3 2

Proposal: Expose raw bwauth votes
by Tom Ritter 16 Jul '18

16 Jul '18

I'm not sure, but I think https://trac.torproject.org/projects/tor/ticket/21377 needed a proposal so I tried to write one up. -tom

5 8

HS v3 client authorization types
by Suphanat Chunhapanya 12 Jul '18

12 Jul '18

As I am currently implementing the client authorization for onion service v3 (https://github.com/torproject/tor/pull/36), I found some problems in how we should let the users configure the client auth for their services. Before getting into the problem, I will explain how it works first. -- Each client will have two private keys to authenticate with the service. One is x25519 key and the other is ed25519 key. The x25519 one is used to decrypt the descriptor when the client wants to access the service, so if the client is not authorized, it will never know the introduction points, the intro auth keys, and so on, and then it absolutely cannot access the service. The ed25519 one is for another layer of authentication. Even if the client can decrypt the descriptor using the x25519 private key, it still need to have the ed25519 to authenticate itself directly to the service using the extension field in INTRODUCE1 cell. At first glance, it seems that the ed25519 one is not necessary because, if the client is able to decrypt the descriptor, it already means the client is already authenticated. Why do we need to have another layer of authenticate? The answer is that the ed25519 provides more find-grained access control for example: 1) you could use it to revoke a client without the need to rotate all the intro points and push new descriptor. 2) you can have more fine-grained control on your users and potentially offer different types of access structure to different users using their ed25519 keys as identifier. -- The spec says that the client must have both keys and use both to authenticate, but, for me, these two things are quite independent. I think they can be considered two different authentication types. The service should be able to enable one and disable the other. For example, If I disable the x25519 while I enable ed25519, I can add a new client immediately without the need to rotate the intro points. If rotating intro points is not an issue and the only purpose of ed25519 is to have more fine-grained access control, the current spec is fine. But if rotating intro points is an issue, we should rethink about this. So, I created a PR for the change in torspec. https://github.com/torproject/torspec/pull/7 (in the PR, the x25519 auth is called 'basic' and the ed25519 auth is called 'intro') We need your opinions about this. Should we let the service enable one while disable the other? Or should we require the service to enable both for all clients? If you want to let the service be able to enable one while disable the other, do you have any opinion on how to configure the torrc? Cheers, haxxpop This is a discussion log that we had earlier. [22:39:23] <meejah> v3 "basic" auth is different from v2 "basic" auth, right? Perhaps a different name-string for the v3 one would be good? [22:39:44] <asn> meejah: good point [22:39:57] <asn> perhaps we can name it "pubkey" auth or something more UX-y [22:40:35] <meejah> asn: sounds good to me (my perspective is to avoid naming-weirdness for controllers and having to explain to users "well, this 'basic' is different from this other 'basic' because you said version=3") [22:40:43] <asn> right [22:40:44] <asn> makse sense [22:40:51] <asn> haxxpop: ^ what do u think [22:40:51] <asn> ? [22:45:01] <haxxpop> meejah, asn yes I agreed. maybe we should change it to something else [22:46:10] <haxxpop> meejah, asn In fact, the word 'basic' appears only once in the v3 spec ! [22:48:05] <asn> haxxpop: yeah... perhaps we can rename it to "pubkey" which describes it pretty well for nerds. or to "standard" which is a synonym for "basic" and it will confuse everyone. [22:50:59] <haxxpop> asn, I think both "basic" and "intro" use pubkeys. [22:51:26] <haxxpop> asn, I think if we call "basic" "pubkey", it may imply that "intro" doesn't use pubkeys. [22:51:35] <asn> true [22:52:20] <asn> i'm still not sure if i like: [22:52:20] <asn> + HiddenServiceAuthorizeClient basic client-name,client-name,... [22:52:20] <asn> + HiddenServiceAuthorizeClient intro client-name,client-name,... [22:52:30] <asn> mainly because it's gonna be quite hard to explain to people what these two lines mean [22:52:34] <asn> (to hs operators) [22:52:37] <asn> like what's the difference [22:52:42] <asn> and usually they should have both enabled [22:52:53] <asn> what i imagined initially is that we would keep the torrc logic the same [22:53:04] <asn> and maybe expose a torrc option for advanced users to do HiddenServiceDisableIntroAuth [22:53:07] <asn> or something [22:53:11] <asn> anyway i need to think about this! [22:53:25] <haxxpop> asn, Nice point [23:08:35] <meejah> asn: haxxpop: "pubkey" sounds good to me. People who are "just clients" probably don't care what the string is (? maybe? UX people?) and people running the services probably count as "nerds" :) [23:08:59] <asn> agreed [23:09:02] <meejah> (but, I don't personally understand what these schemes are so maybe I shouldn't be naming them ;) [23:09:08] <asn> ideally those things should not be exposed to the users anyway [23:09:19] <asn> they should be wrapped by the browser or something [23:11:46] <meejah> asn: in txtorcon at least, they aren't really; preferred new-API is "async with tor.onion_authentication(onion_host, some_auth_object)" for py3, or "tor.add_onion_authentication(..)" -- ideally this can be used by "actual application" to transmit the credentials to users in some way [23:11:52] <meejah> (e.g. maybe via magic-wormhole) [23:12:35] <meejah> I assume that *ideally* the clients generate keypairs, and send pubkeys to the service..? [23:22:45] <asn> meejah: yes ideally clients generate keypairs [23:23:00] <asn> meejah: but service-generated keypairs can also be done, to immitate current symmetric-key design [23:26:08] <dmr> asn: there's lots of reasons to keep v2 "basic" separate from v3 "basic" - limited bug reports, presentations, error/log messages, internet searches, ... [23:26:34] <dmr> like meejah I also don't know what the schemes are, so that's the extent of my input :) [23:26:51] <dmr> glad to hear it sounds like we're all in agreement to use something other than "basic" for v3 [23:46:12] <meejah> asn: okay, ack. It would be neat to see an application using magic-wormhole for an "invite a new client" flow; perhaps I'll try a PoC when v3-auth is available; is it in master already??

6 16

minor website update request: have the tor-relay guide ready for Ubuntu 18.04
by nusenu 28 Jun '18

28 Jun '18

Hi, I wanted to have the tor relay guide ready for the new Ubuntu LTS version 18.04 nearly at the same time when it is released. Thanks to the torproject debian maintainer we already have packages for bionic. Basically the only thing that is missing is the website update to include the new distro for the sources.list generator. For that I submitted an update on trac [1] a few days ago. From my personal experience, my website update requests (also trivial ones) take about two months to get committed, it would be great if we could speed things up for this specific request to have the relay guide ready for the new Ubuntu LTS nearly at the same time when the release is happening. (I won't be bothering you with non-tor-relay-guide related website updates anymore). thanks, nusenu [1] https://trac.torproject.org/projects/tor/ticket/25888 -- https://mastodon.social/@nusenu twitter: @nusenu_

3 4

Proposal 292: Mesh-based vanguards
by George Kadianakis 03 Jun '18

03 Jun '18

Hello list, here is the vanguard proposal that supersedes proposal 247. It specifies the newest vanguard design which we've been working on: https://github.com/mikeperry-tor/vanguards FWIW, the above project is still in experimental state and we are expecting to launch it officially in the short term future. Until then, feel free to experiment with it if you feel like it. Check out the proposal and code and let us know if you have any questions or feedback! Thanks! --- Filename: 292-mesh-vanguards.txt Title: Mesh-based vanguards Authors: George Kadianakis and Mike Perry Created: 2018-05-08 Status: Open Supersedes: 247 0. Motivation A guard discovery attack allows attackers to determine the guard node of a Tor client. The hidden service rendezvous protocol provides an attack vector for a guard discovery attack since anyone can force an HS to construct a 3-hop circuit to a relay (#9001). Following the guard discovery attack with a compromise and/or coercion of the guard node can lead to the deanonymization of a hidden service. 1. Overview This document tries to make the above guard discovery + compromise attack harder to launch. It introduces a configuration option which makes the hidden service also pin the second and third hops of its circuits for a longer duration. With this new path selection, we force the adversary to perform a Sybil attack and two compromise attacks before succeeding. This is an improvement over the current state where the Sybil attack is trivial to pull off, and only a single compromise attack is required. With this new path selection, an attacker is forced to do a one or more node compromise attacks before learning the guard node of a hidden service. This increases the uncertainty of the attacker, since compromise attacks are costly and potentially detectable, so an attacker will have to think twice before beginning a chain of node compromise attacks that they might not be able to complete. 1.1. Tor integration The mechanisms introduced in this proposal are currently implemented partially in Tor and partially through an external Python script: https://github.com/mikeperry-tor/vanguards The Python script uses the new Tor configuration options HSLayer2Nodes and HSLayer3Nodes to be able to select nodes for the guard layers. The Python script is tasked with maintaining and rotating the guard nodes as needed based on the lifetimes described in this proposal. In the future, we are aiming to include the whole functionality into Tor, with no need for external scripts. 1.2. Visuals Here is how a hidden service rendezvous circuit currently looks like: -> middle_1 -> middle_A -> middle_2 -> middle_B -> middle_3 -> middle_C -> middle_4 -> middle_D HS -> guard -> middle_5 -> middle_E -> middle_6 -> middle_F -> middle_7 -> middle_G -> middle_8 -> middle_H -> ... -> ... -> middle_n -> middle_n this proposal pins the two middle positions into a much more restricted sets, as follows: -> guard_2A -> guard_3A -> guard_1A -> guard_2B -> guard_3B HS -> guard_3C -> guard_1B -> guard_2C -> guard_3D -> guard_3E -> guard_2D -> guard_3F Additionally, to avoid linkability, we insert an extra middle node after the third layer guard for client side intro and hsdir circuits, and service-side rendezvous circuits. This means that the set of paths for Client (C) and Service (S) side look like this: C - G - L2 - L3 - R S - G - L2 - L3 - HSDIR S - G - L2 - L3 - I C - G - L2 - L3 - M - I C - G - L2 - L3 - M - HSDIR S - G - L2 - L3 - M - R 1.3. Threat model, Assumptions, and Goals Consider an adversary with the following powers: - Can launch a Sybil guard discovery attack against any node of a rendezvous circuit. The slower the rotation period of the node, the longer the attack takes. Similarly, the higher the percentage of the network is compromised, the faster the attack runs. - Can compromise any node on the network, but this compromise takes time and potentially even coercive action, and also carries risk of discovery. We also make the following assumptions about the types of attacks: 1. A Sybil attack is observable by both people monitoring the network for large numbers of new nodes, as well as vigilant hidden service operators. It will require either large amounts of traffic sent towards the hidden service, multiple test circuits, or both. 2. A Sybil attack against the second or first layer Guards will be more noisy than a Sybil attack against the third layer guard, since the second and first layer Sybil attack requires a timing side channel in order to determine success, whereas the Sybil success is almost immediately obvious to third layer guard, since it will be instructed to connect to a cooperating malicious rend point by the adversary. 3. As soon as the adversary is confident they have won the Sybil attack, an even more aggressive circuit building attack will allow them to determine the next node very fast (an hour or less). 4. The adversary is strongly disincentivized from compromising nodes that may prove useless, as node compromise is even more risky for the adversary than a Sybil attack in terms of being noticed. Given this threat model, our security parameters were selected so that the first two layers of guards should be hard to attack using a Sybil guard discovery attack and hence require a node compromise attack. Ideally, we want the node compromise attacks to carry a non-negligible probability of being useless to the adversary by the time they complete. On the other hand, the outermost layer of guards should rotate fast enough to _require_ a Sybil attack. See our vanguard simulator project for a simulation of the above adversary model and a motivation for the parameters selected within this proposal: https://github.com/asn-d6/vanguard_simulator https://github.com/asn-d6/vanguard_simulator/wiki/Optimizing-vanguard-topol… 2. Design When a hidden service picks its guard nodes, it also picks an additional NUM_LAYER2_GUARDS-sized set of middle nodes for its `second_guard_set`, as well as a NUM_LAYER3_GUARDS-sized set of middle nodes for its `third_guard_set`. When a hidden service needs to establish a circuit to an HSDir, introduction point or a rendezvous point, it uses nodes from `second_guard_set` as the second hop of the circuit and nodes from `third_guard_set` as third hop of the circuit. A hidden service rotates nodes from the 'second_guard_set' at a random time between MIN_SECOND_GUARD_LIFETIME hours and MAX_SECOND_GUARD_LIFETIME hours. A hidden service rotates nodes from the 'third_guard_set' at a random time between MIN_THIRD_GUARD_LIFETIME and MAX_THIRD_GUARD_LIFETIME hours. Each node's rotation time is tracked independently, to avoid disclosing the rotation times of the primary and second-level guards. 2.1. Security parameters We set NUM_LAYER2_GUARDS to 4 nodes and NUM_LAYER3_GUARDS to 6 nodes. We set MIN_SECOND_GUARD_LIFETIME to 1 day, and MAX_SECOND_GUARD_LIFETIME to 45 days inclusive, for an average rotation rate of 29.5 days, using the max(X,X) distribution specified in Section 3.3. We set MIN_THIRD_GUARD_LIFETIME to 1 hour, and MAX_THIRD_GUARD_LIFETIME to 48 hours inclusive, for an average rotation rate of 31.5 hours, using the max(X,X) distribution specified in Section 3.3. See Section 3 for more analysis on these constants. 2.2. Path restriction changes In order to avoid information leaks and ensure paths can be built, path restrictions must be loosened. In particular, we allow the following: 1. Nodes from the same /16 and same family for any/all hops 2. Guard nodes can be chosen for RP/IP/HSDIR 3. Guard nodes can be chosen for hop before RP/IP/HSDIR. The first change prevents the situation where paths cannot be built if two layers all share the same subnet and/or node family. It also prevents the the use of a different entry guard based on the family or subnet of the IP, HSDIR, or RP. The second change prevents an adversary from forcing the use of a different entry guard by enumerating all guard-flaged nodes as the RP. The third change prevents an adversary from learning the guard node by way of noticing which nodes were not chosen for the hop before it. 3. Rationale and Security Parameter Selection 3.1. Sybil rotation counts for a given number of Guards The probability of Sybil success for Guard discovery can be modeled as the probability of choosing 1 or more malicious middle nodes for a sensitive circuit over some period of time. P(At least 1 bad middle) = 1 - P(All Good Middles) = 1 - P(One Good middle)^(num_middles) = 1 - (1 - c/n)^(num_middles) c/n is the adversary compromise percentage In the case of Vanguards, num_middles is the number of Guards you rotate through in a given time period. This is a function of the number of vanguards in that position (v), as well as the number of rotations (r). P(At least one bad middle) = 1 - (1 - c/n)^(v*r) Here's detailed tables in terms of the number of rotations required for a given Sybil success rate for certain number of guards. 1.0% Network Compromise: Sybil Success One Two Three Four Five Six Eight Nine Ten Twelve Sixteen 10% 11 6 4 3 3 2 2 2 2 1 1 15% 17 9 6 5 4 3 3 2 2 2 2 25% 29 15 10 8 6 5 4 4 3 3 2 50% 69 35 23 18 14 12 9 8 7 6 5 60% 92 46 31 23 19 16 12 11 10 8 6 75% 138 69 46 35 28 23 18 16 14 12 9 85% 189 95 63 48 38 32 24 21 19 16 12 90% 230 115 77 58 46 39 29 26 23 20 15 95% 299 150 100 75 60 50 38 34 30 25 19 99% 459 230 153 115 92 77 58 51 46 39 29 5.0% Network Compromise: Sybil Success One Two Three Four Five Six Eight Nine Ten Twelve Sixteen 10% 3 2 1 1 1 1 1 1 1 1 1 15% 4 2 2 1 1 1 1 1 1 1 1 25% 6 3 2 2 2 1 1 1 1 1 1 50% 14 7 5 4 3 3 2 2 2 2 1 60% 18 9 6 5 4 3 3 2 2 2 2 75% 28 14 10 7 6 5 4 4 3 3 2 85% 37 19 13 10 8 7 5 5 4 4 3 90% 45 23 15 12 9 8 6 5 5 4 3 95% 59 30 20 15 12 10 8 7 6 5 4 99% 90 45 30 23 18 15 12 10 9 8 6 10.0% Network Compromise: Sybil Success One Two Three Four Five Six Eight Nine Ten Twelve Sixteen 10% 2 1 1 1 1 1 1 1 1 1 1 15% 2 1 1 1 1 1 1 1 1 1 1 25% 3 2 1 1 1 1 1 1 1 1 1 50% 7 4 3 2 2 2 1 1 1 1 1 60% 9 5 3 3 2 2 2 1 1 1 1 75% 14 7 5 4 3 3 2 2 2 2 1 85% 19 10 7 5 4 4 3 3 2 2 2 90% 22 11 8 6 5 4 3 3 3 2 2 95% 29 15 10 8 6 5 4 4 3 3 2 99% 44 22 15 11 9 8 6 5 5 4 3 The rotation counts in these tables were generated with: def num_rotations(c, v, success): r = 0 while 1-math.pow((1-c), v*r) < success: r += 1 return r 3.2. Rotation Period As specified in Section 1.2, the primary driving force for the third layer selection was to ensure that these nodes rotate fast enough that it is not worth trying to compromise them, because it is unlikely for compromise to succeed and yield useful information before the nodes stop being used. From the table in Section 3.1, with NUM_LAYER2_GUARDS=4 and NUM_LAYER3_GUARDS=6, it can be seen that this means that the Sybil attack on layer3 will complete with 50% chance in 12*31.5 hours (15.75 days) for the 1% adversary, ~4 days for the 5% adversary, and 2.62 days for the 10% adversary. Since rotation of each node happens independently, the distribution of when the adversary expects to win this Sybil attack in order to discover the next node up is uniform. This means that on average, the adversary should expect that half of the rotation period of the next node is already over by the time that they win the Sybil. With this fact, we choose our range and distribution for the second layer rotation to be short enough to cause the adversary to risk compromising nodes that are useless, yet long enough to require a Sybil attack to be noticeable in terms of client activity. For this reason, we choose a minimum second-layer guard lifetime of 1 day, since this gives the adversary a minimum expected value of 12 hours for during which they can compromise a guard before it might be rotated. If the total expected rotation rate is 29.5 days, then the adversary can expect overall to have 14.75 days remaining after completing their Sybil attack before a second-layer guard rotates away. 3.3. Rotation distributions In order to skew the distribution of the third layer guard towards higher values, we use max(X,X) for the distribution, where X is a random variable that takes on values from the uniform distribution. Here's a table of expectation (arithmetic means) for relevant ranges of X (sampled from 0..N-1). The table was generated with the following python functions: def ProbMinXX(N, i): return (2.0*(N-i)-1)/(N*N) def ProbMaxXX(N, i): return (2.0*i+1)/(N*N) def ExpFn(N, ProbFunc): exp = 0.0 for i in xrange(N): exp += i*ProbFunc(N, i) return exp The current choice for second-layer guards is noted with **, and the current choice for third-layer guards is noted with ***. Range Min(X,X) Max(X,X) 40 12.84 26.16 41 13.17 26.83 42 13.50 27.50 43 13.84 28.16 44 14.17 28.83 45 14.50 29.50** 46 14.84 30.16 47 15.17 30.83 48 15.50 31.50*** The Cumulative Density Function (CDF) tells us the probability that a guard will no longer be in use after a given number of time units have passed. Because the Sybil attack on the third node is expected to complete at any point in the second node's rotation period with uniform probability, if we want to know the probability that a second-level Guard node will still be in use after t days, we first need to compute the probability distribution of the rotation duration of the second-level guard at a uniformly random point in time. Let's call this P(R=r). For P(R=r), the probability of the rotation duration depends on the selection probability of a rotation duration, and the fraction of total time that rotation is likely to be in use. This can be written as: P(R=r) = ProbMaxXX(X=r)*r / \sum_{i=1}^N ProbMaxXX(X=i)*i or in Python: def ProbR(N, r, ProbFunc=ProbMaxXX): return ProbFunc(N, r)*r/ExpFn(N, ProbFunc) For the full CDF, we simply sum up the fractional probability density for all rotation durations. For rotation durations less than t days, we add the entire probability mass for that period to the density function. For durations d greater than t days, we take the fraction of that rotation period's selection probability and multiply it by t/d and add it to the density. In other words: def FullCDF(N, t, ProbFunc=ProbR): density = 0.0 for d in xrange(N): if t >= d: density += ProbFunc(N, d) # The +1's below compensate for 0-indexed arrays: else: density += ProbFunc(N, d)*(float(t+1))/(d+1) return density Computing this yields the following distribution for our current parameters: t P(SECOND_ROTATION <= t) 1 0.03247 2 0.06494 3 0.09738 4 0.12977 5 0.16207 10 0.32111 15 0.47298 20 0.61353 25 0.73856 30 0.84391 35 0.92539 40 0.97882 45 1.00000 This CDF tells us that for the second-level Guard rotation, the adversary can expect that 3.3% of the time, their third-level Sybil attack will provide them with a second-level guard node that has only 1 day remaining before it rotates. 6.5% of the time, there will be only 2 day or less remaining, and 9.7% of the time, 3 days or less. Note that this distribution is still a day-resolution approximation. 4. Security concerns and mitigations 4.1. Mitigating fingerprinting of new HS circuits By pinning the middle nodes of rendezvous circuits, we make it easier for all hops of the circuit to detect that they are part of a special hidden service circuit with varying degrees of certainty. The Guard node is able to recognize a Vanguard client with a high degree of certainty because it will observe a client IP creating the overwhelming majority of its circuits to just a few middle nodes in any given 31.5 day time period. The middle nodes will be able to tell with a variable certainty that depends on both its traffic volume and upon the popularity of the service, because they will see a large number of circuits that tend to pick the same Guard and Exit. The final nodes will be able to tell with a similar level of certainty that depends on their capacity and the service popularity, because they will see a lot of handshakes that all tend to have the same second hops. The most serious of these is the Guard fingerprinting issue. When proposal 254-padding-negotiation is implemented, services that enable this feature should use those padding primitives to create fake circuits to random middle nodes that are not their guards, in an attempt to look more like a client. Additionally, if Tor Browser implements "virtual circuits" based on SOCKS username+password isolation in order to enforce the re-use of paths when SOCKS username+passwords are re-used, then the number of middle nodes in use during a typical user's browsing session will be proportional to the number of sites they are viewing at any one time. This is likely to be much lower than one new middle node every ten minutes, and for some users, may be close to the number of Vanguards we're considering. This same reasoning is also an argument for increasing the number of second-level guards beyond just two, as it will spread the hidden service's traffic over a wider set of middle nodes, making it both easier to cover, and behave closer to a client using SOCKS virtual circuit isolation. 5. Default vs optional behavior We suggest this torrc option to be optional because it changes path selection in a way that may seriously impact hidden service performance, especially for high traffic services that happen to pick slow guard nodes. However, by having this setting be disabled by default, we make hidden services who use it stand out a lot. For this reason, we should in fact enable this feature globally, but only after we verify its viability for high-traffic hidden services, and ensure that it is free of second-order load balancing effects. Even after that point, until Single Onion Services are implemented, there will likely still be classes of very high traffic hidden services for whom some degree of location anonymity is desired, but for which performance is much more important than the benefit of Vanguards, so there should always remain a way to turn this option off. In the meantime, a reference implementation is available at: https://github.com/mikeperry-tor/vanguards/blob/master/vanguards/vanguards.… Appendix A: Full Python program for generating tables in this proposal #!/usr/bin/python import math ############ Section 3.1 ################# def num_rotations(c, v, success): i = 0 while 1-math.pow((1-c), v*i) < success: i += 1 return i def rotation_line(c, pct): print " %2d%% %6d%6d%6d%6d%6d%6d%6d%6d%6d%6d%8d" % \ (pct, num_rotations(c, 1, pct/100.0), num_rotations(c, 2, pct/100.0), \ num_rotations(c, 3, pct/100.0), num_rotations(c, 4, pct/100.0), num_rotations(c, 5, pct/100.0), num_rotations(c, 6, pct/100.0), num_rotations(c, 8, pct/100.0), num_rotations(c, 9, pct/100.0), num_rotations(c, 10, pct/100.0), num_rotations(c, 12, pct/100.0), num_rotations(c, 16, pct/100.0)) def rotation_table_31(): for c in [1,5,10]: print "\n %2.1f%% Network Compromise: " % c print " Sybil Success One Two Three Four Five Six Eight Nine Ten Twelve Sixteen" for success in [10,15,25,50,60,75,85,90,95,99]: rotation_line(c/100.0, success) ############ Section 3.3 ################# def ProbMinXX(N, i): return (2.0*(N-i)-1)/(N*N) def ProbMaxXX(N, i): return (2.0*i+1)/(N*N) def ExpFn(N, ProbFunc): exp = 0.0 for i in xrange(N): exp += i*ProbFunc(N, i) return exp def ProbUniformX(N, i): return 1.0/N def ProbR(N, r, ProbFunc=ProbMaxXX): return ProbFunc(N, r)*r/ExpFn(N, ProbFunc) def FullCDF(N, t, ProbFunc=ProbR): density = 0.0 for d in xrange(N): if t >= d: density += ProbFunc(N, d) # The +1's below compensate for 0-indexed arrays: else: density += ProbFunc(N, d)*float(t+1)/(d+1) return density def expectation_table_33(): print "\n Range Min(X,X) Max(X,X)" for i in xrange(10,49): print " %2d %2.2f %2.2f" % (i, ExpFn(i,ProbMinXX), ExpFn(i, ProbMaxXX)) def CDF_table_33(): print "\n t P(SECOND_ROTATION <= t)" for i in xrange(1,46): print " %2d %2.5f" % (i, FullCDF(45, i-1)) ########### Output ############ # Section 3.1 rotation_table_31() # Section 3.3 expectation_table_33() CDF_table_33() ---------------------- 1. https://onionbalance.readthedocs.org/en/latest/design.html#overview

3 2

[release] Onionoo 6.0-1-14-0, ExoneraTor 2.1.0, metrics-web 1.1.0
by iwakeh 31 May '18

31 May '18

Hi there! three new releases are available: https://dist.torproject.org/onionoo/6.0-1.14.0/ https://dist.torproject.org/exonerator/2.1.0/ https://dist.torproject.org/metrics-web/1.1.0/ This is the second batch of releases of Metrics products, which now use a to a better performing JSON processing library. Other details can be found in the respective change logs [0], [1], and [2]. All releases are already deployed on all respective tp.o instances. Please direct comments and questions to the metrics-team mailing list [3]. Cheers, iwakeh [0] https://gitweb.torproject.org/onionoo.git/tree/CHANGELOG.md?h=onionoo-6.0-1… [1] https://gitweb.torproject.org/exonerator.git/tree/CHANGELOG.md?h=exonerator… [2] https://gitweb.torproject.org/metrics-web.git/tree/CHANGELOG.md?h=metrics-w… [3] https://lists.torproject.org/cgi-bin/mailman/listinfo/metrics-team

1 0

(no subject)
by abhinav chowdary 31 May '18

31 May '18

Iam in or out

2 2

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

tor-dev May 2018