- tor-dev - lists.torproject.org

Open Source Design Workshop, Brussels, January 31
by sajolida 04 Dec '19

04 Dec '19

The fine folks at Open Source Design are organizing on January 31 a practical workshop on usability testing: https://hsbxl.be/events/byteweek/2020/opensourcedesign/ It will happen in Brussels, 1 day before FOSDEM. >From the author and the description of the workshop I expect it to imply invaluable knowledge for free. Everybody interested in developing or designing usable software but without academic training on usability testing should attend a workshop like this. I'm not sending this email to UX mailing lists on purpose :) -- sajolida Tails — https://tails.boum.org/ UX · Fundraising · Technical

1 0

HSv3 descriptor work in stem
by George Kadianakis 04 Dec '19

04 Dec '19

Hello atagar, I'm starting this thread to ask you questions about stem and the HSv3 work we've been doing over email so that we don't do it over IRC. Here is an initial question: I'm working on HSv3 descriptor encoding, and I'm trying to understand how `_descriptor_content()` works. In particular, I want to compute the signature of a descriptor, but I see that `descriptor_content()` fills it with random bytes in all the `content()` methods I managed to find: ('signature', _random_crypto_blob('SIGNATURE')), What's the right way to compute the signature for such objects? In particular, I would need a method that first generates the whole descriptor body, and then computes the signature of that with a given private key. Can I use `_descriptor_content()` to do that? Or should I call `_descriptor_content()` to generate the whole thing _without_ the sig, and then do the signature computation on its result and concatenate it after? Thanks! :)

3 10

Practracker regen in #30381
by teor 28 Nov '19

28 Nov '19

Hi George, David, It looks like you regenerated the whole practracker file in #30381: https://trac.torproject.org/projects/tor/ticket/30381 https://github.com/torproject/tor/commit/53ac9a9a91a8f2ab45c755504567160749… But we usually just add exceptions for the files that we modified. When we do a full regeneration, we lose a whole lot of warnings that tell us where our code quality is getting worse. Do you mind if I revert the unrelated changes? T -- teor ----------------------------------------------------------------------

3 4

Proposal 271 - improvements
by Florentin Rochet 26 Nov '19

26 Nov '19

Hello, I'm doing research on improving Tor security via path selection. This work is with Ryan Wails, Aaron Johnson, Prateek Mittal, and Olivier Pereira. In our work, we ran into load-balancing problems that affected our experiments. We identified the problem to originate in the specification and implementation of Proposal 271, "Another algorithm for guard selection", which was implemented in tor-0.3.0.1-alpha ~2 years ago and is thus now in tor stable. In short, Prop 271 causes guards to be selected with probabilities different than their weights due to the way it samples many guards and then chooses primary guards from that sample. We are suggesting a straightforward fix to the problem, which is, roughly speaking, to choose primary guards in the order in which they were sampled. We have created a patch implementing this fix for the case affecting our experiments, which would improve the current situation. We are further suggesting that Tor apply the technique throughout the guard-selection logic. In more detail, Prop 271 chooses guards via a multi-step process: 1. It chooses 20 distinct guards (and sometimes more) by sampling without replacement with probability proportional to consensus weight. 2. It produces two subsets of the sample: (1) "filtered" guards, which are guards that satisfy various torrc constraints, and (2) "confirmed" guards, which are guards through which a circuit has been constructed. 3. The "primary" guards (i.e. the actual guards used for circuits) are chosen from the confirmed and filtered subsets. I'm ignoring the additional "usable" subsets for clarity. This description is based on Section 4.6 of the specification (https://gitweb.torproject.org/torspec.git/tree/guard-spec.txt) The primary guards are selected uniformly at random from the filtered guards when no confirmed guards exist. No confirmed guards appear to exist until some primary guards have been selected, and so when Tor is started the first time the primary guards always come only from the filtered set. The uniformly-random selection causes a bias in primary-guard selection away from consensus weights and towards a more uniform selection of guards. As just an example of the problem, if there were only 20 guards in the network, the sampled set would be all guards and primary guard selection would be entirely uniformly random, ignoring weights entirely. This bias is worse the larger the sampled set is relative to the entire set of guards, and it has a significant effect on Tor simulations, which are typically on smaller networks. We believe that this issue has only a limited effect on Tor currently due to the relatively large number of guards. However, the issue is potentially worse when there exist confirmed guards. In this case, primary guards are chosen from the intersection of confirmed and filtered guards in the order they were added to the confirmed set. That order seems to be the order in which circuits were successfully created through the guards, which would thus be both somewhat non-deterministic (because it depends on when a circuit successfully finishes) and random (because circuits are only attempted through primary guards, which are initially uniformly-random filtered guards). The non-determinism especially could yield guard selection probabilities that deviate quite a bit from the consensus weights. This design has both performance and security implications. It potentially reduces the performance of the Tor network by making the load unbalanced. It also affects the correctness of performance analyses done with Shadow simulations, and the error is likely much larger due to the smaller size of simulation networks, which commonly include 100 or fewer guards. The design also reduces Tor's security by increasing the number of clients that an adversary running small relays can observe. In addition, an adversary has to wait less time than it should after it starts a malicious guard to be chosen by a client. This weakness occurs because the malicious guard only needs to enter the sampled list to have a chance to be chosen as primary, rather than having to wait until all previously-sampled guards have already expired. We propose a solution that fits well within the existing guard-selection algorithm. Our solution is to select primary guards in the order they were sampled. This ordering should be applied after the filtering and/or confirmed guard sets are constructed as normal. That is, primary guards should be selected from the filtered guards (if no guards are both confirmed and filtered) or from the set of confirmed and filtered guards (if such guards exist) in the order they were initially sampled. This solution guarantees that each primary guard is selected (without replacement) from all guards with a probability that is proportional to its consensus weight. We include a patch that applies this ordering only when primary guards are selected from filtered guards. This fixes the problem in Shadow simulations because confirmed guards never exist when primary guards are being selected. However, to solve all issues in the real Tor network, we recommend that you apply similar logic to the case that primary guards are selected from confirmed guards. Note that the issue of sampling skewing guard selection seems to have been raised in proposal discussions, which is documented in the proposal (although the proposed solution is less practical): > [Paul Syverson in a conversation at the Wilmington Meeting 2017 says that > we should look into how we're doing this sampling. Essentially, his > concern is that, since we are sampling by bandwidth at first (when we > choose the `sampled` set), then later there is another bias—when trying to > build circuits (and hence marking guards as confirmed) we select those > which completed a usable circuit first (and hence have the lowest > latency)—that this sort of "doubly skewed" selection may "snub" some > low-consensus-weight guards and leave them unused completely. Thus the > issue is primarily that we're not allocating network resources > efficiently. Mine and Nick's guard algorithm simulation code never > checked what percentage of possible guards the algorithm reasonably > allowed clients to use; this would be an interesting thing to check in > simulation at some point. If it does turn out to be a problem, Paul's > intuition for a fix is to select uniformly at random to obtain the > `sampled` set, then weight by bandwidth when trying to build circuits and > marking guards as confirmed. —isis] Best, Florentin

3 3

introduce some customization on the tbb
by sarpedon montecarlo 21 Nov '19

21 Nov '19

Hello to the community! my first question is that is there a solution for rapid development of tbb? i was wondering that each time a contributor wants to change something in the tbb or add extra functionality, they have to go through the build process which i just guess would be very time consuming. i was wondering that is there any containerized environment for this? any docker ecosystem available or other solutions that might help? my second question is about the changes that i want to implement. i am interested into the graphical settings page about bridges and tor process that currently tbb is exposing to the end users. if we want to add more functionality into this settings page, where should we start to change? and is there any possibility that we may have some control over the underlying tor process as well, for instance controlling it's launching or it's torrc configuration; because as i see, there must be a link between the graphical interface of tbb and the underlying tor process so that is the way we can control bridges for instance. similar to this i was planning to add more graphical options to the interface for controlling other configuration aspects of the tor process through it's torrc or other workarounds. in the past i have achieved this by writing a browser extension that benefits from native messaging for communication to the tor process; but this is not really performance friendly and an intuitive experience for the end users.i am not satisfied with the result. so i was interested on mirroring these functionalities inside tbb. i really appreciate your insights and thoughts on the matter, have a great day, Sarpedon.

3 5

转发： Which elliptic curve Tor use & use safe curve only
by Tom255 21 Nov '19

21 Nov '19

Please use Ed448-Goldilocks or named Curve448 (suggest) and Curve25519 only. Curve448 potentially offering 224 bits of security, even safer than NIST P-384. Curve25519 potentially offering 128 bits of security and safer and faster than NIST P-256. More important, they're both ECC Security, not only ECDLP Security. ECC Security doesn't equal to ECDLP Security. " Unfortunately, there is a gap between ECDLP difficulty and ECC security. None of these standards do a good job of ensuring ECC security. There are many attacks that break real-world ECC without solving ECDLP. The core problem is that if you implement the standard curves, chances are you're doing it wrong: -Your implementation produces incorrect results for some rare curve points. -Your implementation leaks secret data when the input isn't a curve point. -Your implementation leaks secret data through branch timing. -Your implementation leaks secret data through cache timing. " (https://safecurves.cr.yp.to/) And those curves are recommended by RFC 7748: https://tools.ietf.org/html/rfc7748 If possible, use Curve448 only. It's even safer than NIST P-384 and it's new.

1 0

torsocks configure bug (uClibc, maybe other nonstandard libcs)
by akater 14 Nov '19

14 Nov '19

In torsocks' configure.ac, libc_name is determined by means of ldd /usr/bin/yes which is then grepped for libc. On a uClibc system I use, ldd /usr/bin/yes yields two entries, namely libc.so.0 => ... ld64-uClibc.so.0 => ... The resulting string begins with quotation mark, ends with quotation mark and contains newline character. At some point during the configuration process (I have not figured out when exactly), the aforementioned string is trimmed erroneously. In my case, the first line is left out and the second one is discarded. The remaining chunk, with the opening quotation mark but without the closing one, ends up in another configuration file, producing a line like SOME_VARIABLE="libc.so.0 without the closing quotation mark. Build cannot proceed from there. The libc determination process thus needs to be fixed. My hotfix was to change grep 'libc\.' to grep '\slibc\.' but I can't suggest the proper solution as I'm not experienced with shell scripts. I will perform a test if provided with (a link to) a relevant standalone patch for torsocks-2.2.0 or torsocks-2.3.0.

2 1

Acceptable clock skew in tor 0.4.1
by intrigeri 14 Nov '19

14 Nov '19

Hi, recently, tor has become more tolerant to skewed system clocks; great, thanks! At Tails, we would like to take advantage of these improvements in order to remove as much as we can of our not-quite-safe clock fixing code. Our testing suggests that: - A ±24h clock skew is now acceptable in most cases¹: tor bootstraps successfully. - While with a ±48h clock skew, tor fails to bootstrap. Could someone on the network team please confirm that these empirical results match what the code is currently supposed to do? Thanks in advance! [1] In some corner cases I see weird behavior (#32438). And obfs4proxy is stricter than that, which I should report on Trac. Cheers, -- intrigeri

3 2

[paper] Breaking and (Partially) Fixing Provably Secure Onion Routing
by Eugen Leitl 05 Nov '19

05 Nov '19

https://arxiv.org/abs/1910.13772 Breaking and (Partially) Fixing Provably Secure Onion Routing Christiane Kuhn, Martin Beck, Thorsten Strufe (Submitted on 30 Oct 2019) After several years of research on onion routing, Camenisch and Lysyanskaya, in an attempt at rigorous analysis, defined an ideal functionality in the universal composability model, together with properties that protocols have to meet to achieve provable security. A whole family of systems based their security proofs on this work. However, analyzing HORNET and Sphinx, two instances from this family, we show that this proof strategy is broken. We discover a previously unknown vulnerability that breaks anonymity completely, and explain a known one. Both should not exist if privacy is proven correctly. In this work, we analyze and fix the proof strategy used for this family of systems. After proving the efficacy of the ideal functionality, we show how the original properties are flawed and suggest improved, effective properties in their place. Finally, we discover another common mistake in the proofs. We demonstrate how to avoid it by showing our improved properties for one protocol, thus partially fixing the family of provably secure onion routing protocols. Subjects: Cryptography and Security (cs.CR) Cite as: arXiv:1910.13772 [cs.CR] (or arXiv:1910.13772v1 [cs.CR] for this version)

1 0

Onion Service Intro Point Retry Behavior
by David Goulet 01 Nov '19

01 Nov '19

Greetings everyone, After some discussions between arma, mikeperry, asn and I, it is time for a famous tor-dev@ email thread to try to get to a consensus if need be. In the past weeks, a set of HSv3 reachability issues have been found regarding *service* intro points (IP): - hs-v3: Service can keep unused intro points in its list https://bugs.torproject.org/31561 - hs-v3: Service can pick more than HiddenServiceNumIntroductionPoints intro points https://bugs.torproject.org/31548 - hs-v3: Stop using ip->circuit_established flag https://bugs.torproject.org/32094 - hs-v3: Client can re-pick bad intro points https://bugs.torproject.org/31541 - hs-v3: Service circuit retry limit should not close a valid circuit https://bugs.torproject.org/31652 Long story short, couple weeks ago we've almost merged a new behavior on the service side with #31561 that would have ditch an intro point if its circuit would time out instead of retrying it. (Today, a service always retry their intro point up to 3 times on any type of circuit failure.) And here comes the core of the discussion of this thread: Retrying intro point on failure or simply ditch it on failure and pick a new one? Some 7 years ago, this ticket was created and thus we implemented roughly 4 years ago a mechanism that makes a service retry to establish the intro point circuit up to 3 times when it collapses (except for very very specific cases for which we wouldn't): https://bugs.torproject.org/8239 HSv3 tried to be on feature parity there with v2 up until now that the above bugs have been mostly fixed. That being all said, regarding the retry feature, there are pros and cons. I'll try to organize them below based on many adhoc discussions in the past and what I can get from all the tickets up to this day (there could be more! this is just what I could recall and find in the tickets): == Pros == The primary original argument for retrying is based on the mobile use case. If a .onion is running on a cellphone and the network happens to be bad all the sudden, the service is better off to re-establish the intro circuits which would make the retry attempts of the client to finally succeed after a bit instead of having to re-fetch a descriptor and go to the new intro points. Thus, in theory, it is mostly a reachability argument. One question that can arise from this is: Will the client be able to reconnect using the old intro points by the time the service re-established? In other words, is the retry behavior of the *client* allows enough time for the service to stabilize for the mobile use case? I'm curious to learn from people with experience with this! == Cons == Recently, mikeperry raised concerns about the retry behavior all together and proposed to simply ditch each time the intro point instead of retrying. (@Mike, I do invite you to comment here as you mentionned many times rationales for this but I don't have enough IRC backlog :S). == Pros _and_ Cons at the same time == There is a possible Guard discovery attack argument against retrying. But it is nuanced on what exactly constitute a failure and when should it retry vs ditching. Quote from https://trac.torproject.org/projects/tor/ticket/8239#comment:6 FWIW, it's also worth mentioning that making HSes more stubborn towards old IPs might also allow guard discovery attacks from the IP. That is the IP kills incoming circuits, till a compromised middle node is selected, and since the HS is stubborn it will keep on establishing new circuits. This was mentioned by waldo here: https://lists.torproject.org/pipermail/tor-dev/2014-May/006843.html ... which is where the "what is the failure" is important as arma's mentions in the same ticket: That's why you should only stick to your intro point when it's your network that failed (that is, the connection between you and your guard), not the intro circuit. (This is what I meant in the body of the bug in the 'main tricky point' sentence.) We had this discussion before in Tor many times on "how to detect network failures" vs "circuit failures". In other words, if the link to your Guard fails, that would be enough to consider a network failure and thus retry the intro point. But if the circuit collapses due to let say a DESTROY or TRUNCATED cell, then it could be the IP closing it for the purpose of an attack and thus you would select a new intro point. But, it could also be that the middle node died... That one has many false positive. Soooooo, to repeat what I first said at the beginning, today an HSv3 will _always_ retry up to 3 times regardless of the reason why the circuit collapsed. Should that behavior get more refined with the network failed vs circuit close argument? Should we stop at once retrying? Should we change the retry behavior client side to better match the latency of the mobile use case? Whatever we decide, most importantly, we need to document the *why* of this retry/ditch behavior and thus this email thread is I hope a good start to keep a record of the discussions/arguments. Cheers! David -- 5qZaRu0+AqSNqiaTmTpzcIEztqeYQIq7AAfzKdg/2cs=

2 1