April 2017 - tor-dev - lists.torproject.org

non-anonymous ephemeral onion services with stem
by Micah Lee 30 Jan '18

30 Jan '18

The stem documentation for create_ephemeral_hidden_service [1] says: "Changed in version 1.5.0: Added support for non-anonymous services." But I can't figure out to actually use this feature. There doesn't seem to be a new argument to say if you want your onion service to be non-anonymous. It also says, "Changed in version 1.5.0: Added the basic_auth argument." But there's a new basic_auth argument you can pass into the function to use that. [1] https://stem.torproject.org/api/control.html#stem.control.Controller.create…

5 12

Thoughts on the Counter-RAPTOR paper
by Roger Dingledine 20 Jul '17

20 Jul '17

Hi Prateek, Yixin, (and please involve your other authors as you like), (I'm including tor-dev here too so other Tor people can follow along, and maybe even get involved in the research or the discussion.) I looked through "Counter-RAPTOR: Safeguarding Tor Against Active Routing Attacks": https://arxiv.org/abs/1704.00843 For the tl;dr for others here, the paper: a) comes up with metrics for how to measure resilience of Tor relays to BGP hijacking attacks, and then does the measurements; b) describes a way that clients can choose their guards to be less vulnerable to BGP hijacks, while also considering performance and anonymity loss when guard choice is influenced by client location; and c) builds a monitoring system that takes live BGP feeds and looks for routing table anomalies that could be hijack attempts. Here are some hopefully useful thoughts: ----------------------------------------------------------------------- 0) Since I opted to write these thoughts in public, I should put a little note here in case any journalists run across it and wonder. Yay research! We love research on Tor -- in fact, research like this is the reason Tor is so strong. For many more details about our perspective on Tor research papers, see https://blog.torproject.org/blog/tor-heart-pets-and-privacy-research-commun… ----------------------------------------------------------------------- 1a) The "live BGP feed anomaly detection" part sounds really interesting, since in theory we could start using it really soon now. Have you continued to run it since you wrote the paper? Have you done any more recent analysis on its false positive rate since then? I guess one of the real challenges here is that since most of the alerts are false positives, we really need a routing expert to be able to look at each alert and assess whether we should be worried about it. How hard is it to locate such an expert? Is there even such a thing as an expert in all routing tables, or do we need expertise in "what that part of the network is supposed to look like", which doesn't easily scale to the whole Internet? Or maybe said another way, how much headway can we make on automating the analysis, to make the frequency of alerts manageable? I ask because it's really easy to write a tool that sends a bunch of warnings, and if some of them are false positives, or heck even if they're not but we don't know how to assess how bad they really are, then all we've done is make yet another automated emailer. (We've made a set of these already, to e.g. notice when relays change their identity key a lot: https://gitweb.torproject.org/doctor.git/tree/ but often nobody can figure out whether such an anomaly is really an attack or what, so it's a constant struggle to keep the volume low enough that people don't just ignore the mails.) The big picture question is: what steps remain from what you have now to something that we can actually use? 1b) How does your live-BGP-feed-anomaly-detector compare (either in design, or in closeness to actually being usable ;) to the one Micah Sherr was working on from their PETS 2016 paper? https://security.cs.georgetown.edu/~msherr/reviewed_abstracts.html#tor-data… 1c) Your paper suggests that an alert from a potential hijack attempt could make clients abandon the guard for a while, to keep clients safe from hijack attempts. What about second-order effects of such a design, where the attacker's *goal* is to get clients to abandon a guard, so they add some sketchy routes somewhere to trigger an alert? Specifically, how much easier is it to add sketchy routes that make it look like somebody is attempting an attack, compared to actually succeeding at hijacking traffic? I guess a related question (sorry for my BGP naivete) is: if we're worried about false positives in the alerts, how much authentication and/or attribution is there for sketchy routing table entries in general? Can some jerk drive up our false positive rate, by adding scary entries here and there, in a way that's sustainable? Or heck, can some jerk DDoS parts of the Internet in a way that induces routing table changes that we think look sketchy? These are not reasons to not take the first steps in the arms race, but it's good to know what the later steps might be. ----------------------------------------------------------------------- 2a) Re changing guard selection, you should check out proposal 271, which resulted in the new guard-spec.txt as of Tor 0.3.0.x: https://gitweb.torproject.org/torspec.git/tree/guard-spec.txt I don't fully understand it yet (so many things!), but I bet any future guard selection change proposal should be relative to this design. 2b) Your guard selection algorithm makes the assumption that relays with the Guard flag are the only ones worth choosing from, and then describes a way to choose from among them with different weightings. But you could take a step back, and decide that resilience to BGP hijack should be one of the factors for whether a relay gets the Guard flag in the first place. It sounded from your analysis like some ASes, like OVH, are simply bad news for (nearly) all Tor clients. Your proposed guard selection strategy reduced, but did not eliminate, the chances that clients would get screwed by picking one of these OVH relays. And the tradeoff was that by only reducing the chances, you left the performance changes not as extreme as you might have otherwise. How much of the scariness of a relay is a function of the location of the particular client who is considering using it, and how much is a function of the average (expected) locations of clients? That is, can we identify relays that are likely to be bad news for many different clients, and downplay their weights (or withhold the Guard flag) for everybody? The advantage of making the same decision for all clients is that you can get rid of the "what does guard choice tell you about the client" anonymity question, which is a big win if the rest of the effects aren't too bad. Which leads me to the next topic: ----------------------------------------------------------------------- 3) I think you're right that when analyzing a new path selection strategy, there are three big things to investigate: a) Does the new behavior adequately accomplish the goal that made you want a new path selection strategy (in this case resilience to BGP attacks)? b) What does the new behavior do to anonymity, both in terms of the global effect (e.g. by flattening the selection weights or by concentrating traffic in fewer relays or on fewer networks) and on the individual epistemic side (e.g. by leaking information about the user because of behavior that is a function of sensitive user details)? c) What are the expected changes to performance, and are there particular scenarios (like high load or low load) that have higher or lower impact? I confess that I don't really buy your analysis for 'b' or 'c' in this paper. Average change in entropy doesn't tell me whether particular user populations are especially impacted, and a tiny Shadow simulation with one particular network load and client behavior doesn't tell me whether things will or won't get much worse under other network loads or other client behavior. I can't really fault this paper though, because the structure of an academic research paper means you can only do so much in one paper, and you did a bunch of other interesting things instead. We, the Tor research community, really need better tools for reasoning about the interaction between anonymity and performance. In fact, there sure have been a lot of Tor path selection papers over the past decade which each invent their own ad hoc analysis approach for showing that their proposed change doesn't impact anonymity or performance "too much". Is it time for a Systemization of Knowledge paper on this area -- with the goal of coming up with best practices that future papers can use to provide more convincing analysis? --Roger

2 1

Proposal 247 (Hidden Service Vanguards) Overhaul
by Mike Perry 10 Jun '17

10 Jun '17

I spent some time trying to clean up proposal 247 based on everyone's comments, as well as based on my own thoughts. Please have a look if you commented on the original proposal, and complain if I've not taken your thoughts into account. (Aaron: In particular, I made several tradeoffs in favor of performance and DoS resistance that may be at odds with some of your suggestions, but I think the end result is still OK after looking into the Sybil rates and thinking about the adversary model in more detail. You may disagree). I've attached my updated version of the proposal inline in this mail, but the canonical updated proposal is in my remote at: https://gitweb.torproject.org/user/mikeperry/torspec.git/tree/proposals/247… Here's a summary of the changes (which are also listed in Git): * Try to make a coherent threat model and specify its assumptions * Fold in my comments about using disjoint sets ("buckets") for the third level guard. * Make the parameter discussion subsection its own section, and include tables with far more detail for the Sybil success rates. * Put the rotation period in a separate subsection from the number of guards * Switch to using min(X,X) and max(X,X) for the distribution for the second and third layer guard lifespans, respectively. Add a subsection describing this distribution (3.2.3) * Changed the default parameters based on these tables, and based on my own intuition about Tor's performance properties. * Move the load balancing, torrc, and other performance considerations to their own section (Section 5). * Move "3.2. Distinguishing new HS circuits from normal HS circuits" to section 4.1. * Fold in some of "3.3. Circuit nodes can now be linked to specific hidden services" into 4.1. Some of it I just removed, though, because I did not find it credible. * Added Roger's concerns about guard linkability to Section 4.2. * Added a denial of service subsection to Section 4.3. ================================ Filename: 247-hs-guard-discovery.txt Title: Defending Against Guard Discovery Attacks using Vanguards Author: George Kadianakis Created: 2015-07-10 Status: Draft 0. Motivation A guard discovery attack allow 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 an optional 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 he might not be able to complete. 1.1. 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 -> Rendezvous Point -> middle_6 -> middle_F -> middle_7 -> middle_G -> middle_8 -> middle_H -> ... -> ... -> middle_n -> middle_n this proposal pins the two middles nodes to a much more restricted set, as follows: -> guard_3A_A -> guard_2_A -> guard_3A_B -> guard_3A_C -> Rendezvous Point HS -> guard_1 -> guard_3B_D -> guard_2_B -> guard_3B_E -> guard_3B_F -> Rendezvous Point Note that the third level guards are partitioned into buckets such that they are only used with one specific second-level guard. In this way, we ensure that even if an adversary is able to execute a Sybil attack against the third layer, they only get to learn one of the second-layer Guards, and not all of them. This prevents the adversary from gaining the ability to take their pick of the weakest of the second-level guards for further attack. 2. Design This feature requires the HiddenServiceGuardDiscovery torrc option to be enabled. When a hidden service picks its guard nodes, it also picks two additional sets of middle nodes `second_guard_set` and `third_guard_set` of size NUM_SECOND_GUARDS and NUM_THIRD_GUARDS respectively for each hidden service. These sets are unique to each hidden service created by a single Tor client, and must be kept separate and distinct. 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 that second hop's corresponding `third_guard_set` as third hops 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. These extra guard nodes should be picked with the same path selection procedure that is used for regular middle nodes (though see Section 5.1 for performance reasons to restrict this slightly). Each node's rotation time is tracked independently, to avoid disclosing the rotation times of the primary and second-level guards. XXX how should proposal 241 ("Resisting guard-turnover attacks") be applied here? 2.1. Security parameters We set NUM_SECOND_GUARDS to 4 nodes and NUM_THIRD_GUARDS to 16 nodes (ie four sets of four). XXX: 3 and 12 might be another option here, in which case our rotation period for the second guard position can be reduced to 15 days. We set MIN_SECOND_GUARD_LIFETIME to 1 day, and MAX_SECOND_GUARD_LIFETIME to 33 days, for an average rotation rate of ~11 days, using the min(X,X) distribution specified in Section 3.2.2. We set MIN_THIRD_GUARD_LIFETIME to 1 hour, and MAX_THIRD_GUARD_LIFETIME to 18 hours, for an average rotation rate of ~12 hours, using the max(X,X) distribution specified in Section 3.2.2. XXX make all the above consensus parameters? Yes. Very yes, especially if we decide to change the primary guard lifespan. See Section 3 for more analysis on these constants. 3. Rationale and Security Parameter Selection 3.1. 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 noisy. It will require either large amounts of traffic, 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, where as the Sybil success is almost immediately obvious to third layer guard, since it will now be returned as a rend point for circuits for the hidden service in question. 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. 3.2. Parameter Tuning 3.2.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 count_rotations(c, v, success): r = 0 while 1-math.pow((1-c), v*r) < success: r += 1 return r 3.2.2. Rotation Period As specified in Section 3.1, 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. For this reason we chose 1 to 18 hours, with a weighted distribution (Section 3.2.3) causing the expected average to be 12 hours. From the table in Section 3.2.1, it can be seen that this means that the Sybil attack will complete with near-certainty (99%) in 29*12 hours (14.5 days) for the 1% adversary, 3 days for the 5% adversary, and 1.5 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 11 days, then the adversary can expect overall to have 5.5 days remaining after completing their Sybil attack before a second-layer guard rotates away. 3.2.3. Rotation distribution 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. In order to skew the distribution of the second layer guard towards low values (to increase the risk of compromising useless nodes) we skew the distribution towards lower values, using min(X,X). Here's a table of expectation (arithmetic means) for relevant ranges of X (sampled from 0..N). 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) 10 2.85 6.15 11 3.18 6.82 12 3.51 7.49 13 3.85 8.15 14 4.18 8.82 15 4.51 9.49 16 4.84 10.16 17 5.18 10.82*** 18 5.51 11.49 19 5.84 12.16 20 6.18 12.82 21 6.51 13.49 22 6.84 14.16 23 7.17 14.83 24 7.51 15.49 25 7.84 16.16 26 8.17 16.83 27 8.51 17.49 28 8.84 18.16 29 9.17 18.83 30 9.51 19.49 31 9.84 20.16 32 10.17** 20.83 33 10.51 21.49 34 10.84 22.16 35 11.17 22.83 36 11.50 23.50 37 11.84 24.16 38 12.17 24.83 39 12.50 25.50 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 10-18 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 certainty that depends on their capacity and the service popularity, because they will see a lot of rend handshakes that all tend to have the same second hop. The most serious of these is the Guard fingerprinting issue. When proposal xxx-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. 4.2. Hidden service linkability Multiple hidden services on the same Tor instance should use separate second and third level guard sets, otherwise an adversary is trivially able to determine that the two hidden services are co-located by inspecting their current chosen rend point nodes. Unfortunately, if the adversary is still able to determine that two or more hidden services are run on the same Tor instance through some other means, then they are able to take advantage of this fact to execute a Sybil attack more effectively, since there will now be an extra set of guard nodes for each hidden service in use. For this reason, if Vanguards are enabled, and more than one hidden service is configured, the user should be advised to ensure that they do not accidentally leak that the two hidden services are from the same Tor instance. 4.3. Denial of service Since it will be fairly trivial for the adversary to enumerate the current set of rend nodes for a hidden service, denial of service becomes a serious risk for Vanguard users. For this reason, it is important to support a large number of third-level guards, to increase the amount of resources required to bring a hidden service offline by DoSing just a few Tor nodes. 5. Performance considerations The switch to a restricted set of nodes will very likely cause significant performance issues, especially for high-traffic hidden services. If any of the nodes they select happen to be temporarily overloaded, performance will suffer dramatically until the next rotation period. 5.1. Load Balancing Since the second and third level "guards" are chosen from the set of all nodes eligible for use in the "middle" hop (as per hidden services today), this proposal should not significantly affect the long-term load on various classes of the Tor network, and should not require any changes to either the node weight equations, or the bandwidth authorities. Unfortunately, transient load is another matter, as mentioned previously. It is very likely that this scheme will increase instances of transient overload at nodes selected by high-traffic hidden services. One option to reduce the impact of this transient overload is to restrict the set of middle nodes that we chose from to some percentage of the fastest middle-capable relays in the network. This may have some impact on load balancing, but since the total volume of hidden service traffic is low, it may be unlikely to matter. 5.2. Circuit build timeout The adaptive circuit build timeout mechanism in Tor is what corrects for instances of transient node overload right now. The timeout will naturally tend to select the current fastest and least-loaded paths even through this set of restricted routes, but it may fail to behave correctly if there are a very small set of nodes in each guard set, as it is based upon assumptions about the current path selection algorithm, and it may need to be tuned specifically for Vanguards, especially if the set of possible routes is small. 5.3. OnionBalance At first glance, it seems that this scheme makes multi-homed hidden services such as OnionBalance[1] even more important for high-traffic hidden services. Unfortunately, if it is equally damaging to the user for any of their multi-homed hidden service locations to be discovered, then OnionBalance is strictly equivalent to simply increasing the number of second-level guard nodes in use, because an active adversary can perform simultaneous Sybil attacks against all of the rend points offered by the multi-homed OnionBalance introduction points. 5.4. 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. 6. Future directions Here are some more ideas for improvements that should be done sooner or later: - Maybe we should make the size and rotation period of secondary/third guard sets to be configurable by the user. - To make it harder for an adversary, a hidden service MAY extend the path length of its circuits by an additional static hop. This forces the adversary to use another coercion attack to walk the chain up to the hidden service. 7. Acknowledgments Thanks to Aaron Johnson, John Brooks, Mike Perry and everyone else who helped with this idea. 1. https://onionbalance.readthedocs.org/en/latest/design.html#overview -- Mike Perry

7 14

Prop279 and DNS
by Jeremy Rand 29 Apr '17

29 Apr '17

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hello! Maybe this topic has already been brought up, but in case it hasn't, I'll do so. I notice that Prop279 (onion naming API) defines its own API rather than using DNS. I guess that this is because of security concerns about the centralization of the DNS. However, in case you're unaware, Namecoin is designed to interoperate with DNS. Let's say that, hypothetically, Tor defined a DNS-based naming system for onion services, where "_tor.example.com" had a TXT record that was verified with DNSSEC in order to make Tor direct "example.com" to whatever that TXT record had. If this were done, Namecoin would be able to produce the necessary TXT record and DNSSEC signatures, via the standard DNS protocol, using an authoritative nameserver that runs on localhost. (The DNSSEC keys used would be unique per user, generated on installation.) Indeed, this is how we're planning to interoperate with non-proxy-based Internet applications. My guess is that it would be a lot less work on Namecoin's end if such a system were used with Tor rather than a separate naming API. It's unclear to me how this would affect other naming systems such as GNS (does GNS interoperate with clients that use DNS?), and it's also unclear to me whether this would produce extra work for the Tor developers (maybe DNS adds extra attack surface that would need to be mitigated somehow, or maybe there would be complexity in implementing stream isolation?). Anyway, just figured I'd bring up the topic so that everyone's on the same page regarding figuring out whether it's a good idea. Cheers, - -- - -Jeremy Rand Lead Application Engineer at Namecoin Mobile email: jeremyrandmobile(a)airmail.cc Mobile PGP: 2158 0643 C13B B40F B0FD 5854 B007 A32D AB44 3D9C Send non-security-critical things to my Mobile with PGP. Please don't send me unencrypted messages. My business email jeremy(a)veclabs.net is having technical issues at the moment. -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJY4rf2AAoJELPy0WV4bWVwviQP+wSz9/L8czef+L+viSIIrrtv BOp32fysFWw1HijQ/42IoELPhkkzsHjek4IuW6Hn3VHGYs9vJ+rQ9aOcCMGNGD/f f7ktcw3upH/UHiFPp2S0LeNqaoup8qvUQxG/AeP5R20gD/660ZXuIVl4uOaOu5HJ IaghO9ZpzSF695H97hf7bz3H3Wrmch8tjC+FZ+SwWdgqGa4ijjZbTvkypcPEZ6YI YQ22PmoQQWQBbe9JLujLa46PwRWU+UKsppmQYi7dY9K7aO7/J9eKQnOLkUWtdKrN WjtJMV+V4oL/g4IiJrPs5n82pGSvpFi/dMrakoGq2w+v1dJolz/lSGUj7+sWVQZl iqoq6c+l7MjKNynmj/Yn8IquhhwRmVAj4sjV+2jUeVmAf/tHDCBsDYvIDcDeIblu j6y9e7ePTlMTpuxbZ7OKJjsWgGF5+yumWHPtJYs9uBoATeYDM6+Gxm73rDZxRVCl +KGN1jMuREA9N1ZiWuK/ueeeZWGHii4L4UWvdK0qriSvc0HxaQeCGlovEDfO8btO ZDfq9P6USEZywqFyzjzvOUwxnhihwNMdFiSt0RfxLuX34H6POvFYHhw85ESlliY8 0RPjHW6GZywNuOgpYDu9kPS6HPFhXUtok708Jmc926ctX2TT0CJlK6Fl3R2kZGCa nOLHLSYVmkehj6u3RdBf =Hz3g -----END PGP SIGNATURE-----

5 7

Tor Tech Report 2017-04-001 available
by iwakeh 29 Apr '17

29 Apr '17

Hi there! A new Tor Tech Report is available [0]: "Privacy analysis of Tor's in-memory statistics." Abstract: "This report analyzes which possibly sensitive, potentially personally identifying data is stored in memory of Tor relays and bridges or reported to the directory authorities and makes suggestions to reduce the collection and temporary storage of such data." The report addresses concerns regarding metrics collection about the Tor network that were often raised and discussed in the community. Many topics can only be briefly touched in the scope of such a report. Thus, there is quite some work in thinking, writing, and coding open to be done. Based on the report's suggestions the Metrics Team plans the following steps (mainly in May and June 2017): * Distill a change proposal for Tor server changes that address the most pressing of the identified issues. * Code the Tor server patches according to the proposal. * And, provide necessary patches for Tor Metrics products concerned by the changes for Tor servers. Future plans for the months after that are to assess privacy questions as raised in this report more in-depth and describe statistical accuracy throughout the data-verse of Tor Metrics. Many thanks to Aaron Johnson, Paul Syverson, Rob Jansen, and Tim Wilson-Brown, who gave very valuable feedback to ideas and questions we asked during the Amsterdam meeting! Also many thanks to Karsten Loesing, who collected the feedback in Amsterdam, patiently answered all questions about the details of Tor and Tor Metrics, and reviewed the report! Cheers! iwakeh [0] https://research.torproject.org/techreports/privacy-in-memory-2017-04-28.pdf

1 0

txtorcon 0.19.0
by meejah 27 Apr '17

27 Apr '17

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I'm very happy to release txtorcon 0.19.0. This merges most of the development that happened over the last several months on the release-1.x branch. Featuring: * Full Python3 support (and universal wheels) * Drop txsocksx and use a custom implementation (this also implements the custom Tor SOCKS5 methods RESOLVE and RESOLVE_PTR). Uses Automat for the state-machine. * Drop support for older Twisted releases (12, 13 and 14 are no longer supported). * Add a top-level API object (txtorcon.Tor) that abstracts a running Tor. Instances of this class are created with txtorcon.connect or txtorcon.launch. These instances are intended to be "the" high-level API and most users shouldn't need anything else. * Integrated support for twisted.web.client.Agent, baked into txtorcon.Tor. This allows simple, straightforward use of treq or "raw" twisted.web.client for making client-type Web requests via Tor. Automatically handles configuration of SOCKS ports. * new high-level API for putting streams on specific Circuits. This adds txtorcon.Circuit.stream_via and txtorcon.Circuit.web_agent methods that work the same as the "Tor" equivalent methods except they use a specific circuit. This makes txtorcon.TorState.set_attacher the "low-level" / "expert" interface. Most users should only need the new API. * big revamp / re-write of the documentation, including the new Programming Guide: https://txtorcon.readthedocs.io/en/latest/guide.html * Issue 203: https://github.com/meejah/txtorcon/issues/203 * new helper: txtorcon.Router.get_onionoo_details which downloads JSON for a particular relay from OnionOO * new helper: txtorcon.util.create_tbb_web_headers which returns headers resembling a recent Tor Browser suitable for use with Twisted or treq web agents. * Issue 72: https://github.com/meejah/txtorcon/issues/72 * Specific SocksError subclasses for all the available SOCKS5 errors added by https://github.com/felipedau * (more) Python3 fixes from https://github.com/rodrigc You can download the release from PyPI or GitHub (or of course "pip install txtorcon"): https://pypi.python.org/pypi/txtorcon/0.19.0 https://github.com/meejah/txtorcon/releases/tag/v0.19.0 Releases are also available from the hidden service: http://timaq4ygg2iegci7.onion/txtorcon-0.19.0.tar.gz http://timaq4ygg2iegci7.onion/txtorcon-0.19.0.tar.gz.asc You can verify the sha256sum of both by running the following 4 lines in a shell wherever you have the files downloaded: cat <<EOF | sha256sum --check 09d56fbd6e33eef7405c8ca354bbba06da2cefa02763d15c4bc9ac274c5daeeb dist/txtorcon-0.19.0.tar.gz cc51b4249ad126c31ea2746ec5ef1bcb7f6b0c34ced070913ed7772c0e48edf5 dist/txtorcon-0.19.0-py2.py3-none-any.whl EOF thanks, meejah -----BEGIN PGP SIGNATURE----- iQEcBAEBAgAGBQJY+ZjOAAoJEMJgKAMSgGmnadEH/R0YCoID3xTkbFL7mVhtqY2e p7sPcFT50jUGDASaER2YoQ4syzptnQcLid5/pCf+F2xMwCVgayqaipNXtugNHZIl 9cCOnI09+IntCFLkVXQqMGnEzSSzcM0Ln87Qa9MMjNNZM+aj2WshmFnObdqsWNRo tIhnuKgMDgqoO9OgiXCsUXFQeooDDidnrnJgl5U7AA0+13nIar+/q9vCxMtDqSV9 kfh5IkB4RaeJTzDtTMYQKKHTIltdn7o0LrCyp1QsMhX+iHU4xZVOi7etgFnACqsP S1u2LMT1FggvyEAzIwn45ADhKpuPBrR35N5C21vQklHVEb9nQxI9LXTHCi0Fv5g= =mGZj -----END PGP SIGNATURE-----

1 1

Tor 0.3.1 ticket triage: please do this today if you hack on Tor.
by Nick Mathewson 26 Apr '17

26 Apr '17

Hi! We've got 3 weeks left in the 0.3.1 merge window (which closes on May 15) so let's try to triage the tickets. Here's what to do if you are going to develop anything for Tor 0.3.1: - Make sure that everything you are going to do for 031 is assigned to you, in the 0.3.1 milestone, and has a points estimate. ("Points" is a rough "how many days will this take me?" guess.) - If there is anything assigned to you for 031 that you _won't_ be doing for May 15, or that you won't be doing at all, please unassign it and/or defer it from the 031-milestone. - If your total points estimate is over 12 or so (or whatever number of programming days you think you will have, please defer the less important things, or tag them with 031-stretch. Then, in 24 hours or so, for all the tickets that don't get an owner, I will either defer them or mark them "too important to defer" and look for somebody else to do them. Let's see how this works! -- Nick

2 1

Action items wrt ed25519 onion address verification in prop224 (was Re: [tor-project] Network team meetings notes from 17 April 2017)
by George Kadianakis 25 Apr '17

25 Apr '17

Ian Goldberg <tor(a)cypherpunks.ca> writes: > On Thu, Apr 20, 2017 at 03:40:58PM +0300, George Kadianakis wrote: >> Hey Ian, >> >> so the current problem with ed25519-donna is that when I'm doing the >> above, I'm getting the following 32-byte key after ge25519_pack(). Here >> it is hexed up: >> >> 0x0100000000000000000000000000000000000000000000000000000000000000 >> >> I don't see any methods in ed25519-donna for checking a point or a >> packed point to see if it's the point at infinity (identity element). > > There actually is such a function, but it's buried in a weird place. > ge25519_is_neutral_vartime in ed25519-donna-batchverify.h does what you > want, but it's static, so you would need to copy it (and remove the line > involving batch_point_buffer). Probably not worthwhile. > > I can easily believe the representation of the identity (neutral) > element in ed25519 is the hex value above. (And it is; see below.) > >> I've been assuming that the point at infinity would be an all-zeroes >> 32-byte array, because that's what we are doing in curve25519, but I >> actually have no idea how the array representation of ge25519_pack() >> works. Here is our process for curve25519: >> https://gitweb.torproject.org/tor.git/tree/src/common/crypto_curve25519.c#n… > > Curve25519 only outputs the x coordinate, which is indeed 0, so you get > the all-zero value. ed25519 outputs the y coordinate (which is the > 255-bit value 0x000...0001 in little-endian format) and the single-bit > parity of the x coordinate (which is 0), so you do get the hex you give > above. (The identity element is the point (0,1) in Edwards curves, not > actually the point at infinity.) > >> The above packed point is an all zeroes 32-byte string, apart from the >> very first bit which is set. Could it be that the first bit is the >> compressed sign of the 'x' coordinate or something, and that's actually >> the point at infinity? >> >> But then what's the right way to check for the point at infinity? Check >> that everything is 0 apart from the first sign bit? > > Yes, pack the point, and compare it to the above 32-byte value. > >> And after I figure this out, I need to do the same for the reference >> implementation of ed25519, because as it seems Tor uses two simultaneous >> implementations of ed25519: >> https://gitweb.torproject.org/tor.git/tree/src/ext/ed25519 > > Yes, hopefully that implementation packs points in the same way! > >> Thanks for the help Ian :) Very much appreciated! > > No worries. > [CCing tor-dev since people might find it interesting] Thanks for the advice Ian :) With your help, I have now implemented the validation check. Check out the ticket #22006 and the branch `bug22006` here: https://gitweb.torproject.org/user/asn/tor.git/commit/?h=bug22006&id=628dd1… One last thing I'd like to do here is test our validation function against a pubkey with torsion component to make sure that it gets rejected. How would you go about generating such a pubkey? I was thinking of using the CRT to find an integer a \in Z, s.t a == 0 (mod l) && a == 1 (mod 8) but then I didn't know how to go from that scalar with a torsion component to an ed25519 point... Cheers!

2 4

Experimental Namecoin naming for Tor
by Jeremy Rand 24 Apr '17

24 Apr '17

Hi, I've pushed some experimental code for using Namecoin naming in Tor. The code is at https://github.com/JeremyRand/OnioNS-client , you want the "namecoin" branch. Rough instructions: 1. Install Namecoin Core and let it fully download the blockchain. (SPV support is in the works.) 2. Enable JSON-RPC with user/password authentication in Namecoin Core. (The procedure is identical as in Bitcoin Core.) 3. Set your Namecoin Core JSON-RPC login info in the init_namecoind function of src/assets/onions-stem.py. 4. Start Tor Browser Bundle. 5. Run src/assets/onions-stem.py. 6. The first time you run it, it will instruct you to add a line to one of the Tor config files; do this. Specifically, it will ask you to add the line "__LeaveStreamsUnattached 1" to torrc-defaults. 7. Start Tor Browser Bundle again. 8. Run src/assets/onions-stem.py again. 9. Try opening a Namecoin website in Tor Browser. Example websites that I've verified to work include: http://duckduckgo-onion.bit.onion http://bitcoinpl.bit http://federalistpapers.bit.onion http://botball.bit (gives a Dreamhost error) The .bit.onion sites should also work as plain .bit. Semantically, .bit.onion means that it will always resolve to a .onion address (meaning that .bit.onion names are encrypted and authenticated regardless of whether TLS is used); .bit means that it will resolve to any of .onion, IPv6, IPv4, or CNAME (prioritized in that order), meaning that .bit names are only encrypted and authenticated if TLS is used. These semantics are open to revision later, as the Tor community evolves its canonical naming semantics. This is all proof of concept for now; some or all of this code will be rewritten later (hopefully to use the pluggable naming API instead of the control port). It will probably not work with Whonix/Tails/Subgraph due to the control port filter. It will definitely make your Tor Browser instance stand out, since most users can't resolve Namecoin domain names. And since it accesses the control port, it could presumably do lots of horrible things to your Tor instance (and I make no guarantees that it's properly sanitizing the input that's passed to Tor's control port). Huge thanks to Jesse for OnioNS (on which this code is based), and also thanks to Nick for sharing helpful info on this mailing list. Let me know how it works for you. Cheers, -- -Jeremy Rand Lead Application Engineer at Namecoin Mobile email: jeremyrandmobile(a)airmail.cc Mobile OpenPGP: 2158 0643 C13B B40F B0FD 5854 B007 A32D AB44 3D9C Send non-security-critical things to my Mobile with OpenPGP. Please don't send me unencrypted messages. My business email jeremy(a)veclabs.net is having technical issues at the moment.

2 1

Provisional Draft of Hyphae
by isis agora lovecruft 22 Apr '17

22 Apr '17

Hello! Henry and I have written up a provisional draft design for a social bridge distribution scheme, modelled after rBridge, which we're calling Hyphae. For those further interested, here is a draft PDF. [0] Included within is: - A technical history, with primary sources, of censorship of the Tor network, as well as remediations for those censorship attempts; - A description of the bridge distribution problem, including orthogonal problems and solutions, and prior proposals specific to the bridge distribution; - A description of an algebraic-MAC attribute-based credential scheme, requisite non-interactive zero-knowledge proofs, and sub-credentials and tokens, which we use to build our bridge distribution protocol; - A centralised, anonymous micropayments scheme, which we hope is of interest to other projects (such as Brave); - A description of our Hyphae protocol; - An high-level, cryptographic and protocol design comparison to the rBridge protocol; and - Draft notes on our implementation. Please note that this is a provisional draft paper, containing the design but not yet containing results specific to our implementation. We expect some things to change in minor ways during further refinement and implementation. That said, we welcome all feedback and appreciate review. [0]: https://patternsinthevoid.net/hyphae/hyphae.pdf Best regards, -- ♥Ⓐ isis agora lovecruft _________________________________________________________ OpenPGP: 4096R/0A6A58A14B5946ABDE18E207A3ADB67A2CDB8B35 Current Keys: https://fyb.patternsinthevoid.net/isis.txt

1 0