October 2015 - tor-dev - lists.torproject.org

Update of prop#250: Random Number Generation During Tor Voting
by David Goulet 09 Nov '15

09 Nov '15

Hello Tor-Dev! We've almost completed the implementation [1] for prop#250 so we've reviewed part of the proposal to correct part of it to reflect reality (because you know a proposal is just wishful thinking until you implement it :). Attached is the new version that we've been working on. We would like feedback from the community before at least calling it "ACCEPTED" and updated in tor-spec.git [2]. Here is a small summary of the big changes and also we need feedback on something that we are not fully in agreement. First, period have been changed from 12:00 -> 12:00 (24 hour) to 00:00 -> 24:00 so the protocol run is not over two days. Seemed more logical and less confusing :). Second, we've removed the need of having majority for a commit to be considered for the shared random computation. Yes this sounds intense!! so it needs your attention. We think that majority concept was only protecting us against was a partition attack during commit phase but it turns out that having a conflict detection mechanism (see COMMITCONFLICT section) already protect us of most of them during the commit phase except maybe one that is described in Section 5.3.1. With this proposal change, an authority only keeps commits that are authoritative that is a commit coming directly from an authority. We've added section 5.3 on Partition Attack. Choosing commit by majority was protecting us against a partition attack in the commit phase but not all so with or without it, we still need an external monitoring party that makes sure attack are not ongoing (or bugs). DocTor is the obvious candidate so we'll work on a partition attacks detection since all of them are noisy and detectable. A sub-section (4.1.7) has also been added which address the need of a shared random key that signs the commit values so they can be verified by other authorities [3]. Finally, we would like your opinion also on if we should keep the conflict mechanism or not?. Since those partition attacks are basically dumb, do not achive much result for an attacker and it's at a high cost of comprimising a directory authority, should we keep them? Keep in mind that it adds a layer of complexity in the code especially with shared random keys which rotates every 30 days and are only available in the vote of an authority. It gets difficult to validate a conflict of an authority if we haven't seen yet a vote from that authority. There are ways to fix that code wise but is this worth it considering that every partition attack will be detected anyway by DocTor? One argument to keep it is resilience of the protocol. With conflict line, if one dirauth does stupid things, it will get ignored for the rest of the protocol run so we can still compute a fresh random value in the end. Again, does it worth it? Don't hesitate to ask about sections that are not clear or could be incorrect or you do not understand fully. Also, a ACK is a valid reply :). Thanks to all! David [1] https://trac.torproject.org/projects/tor/ticket/16943 [2] https://gitweb.torproject.org/torspec.git/tree/proposals/250-commit-reveal-… [3] https://trac.torproject.org/projects/tor/ticket/17349

5 9

Proposal 258: Denial-of-service resistance for directory authorities
by Nick Mathewson 06 Nov '15

06 Nov '15

[Here's a new proposal from Andrea. See ticket 4581 for implementation details.] Filename: 258-dirauth-dos.txt Title: Denial-of-service resistance for directory authorities Author: Andrea Shepard Created: 2015-10-27 Status: Open 1. Problem statement The directory authorities are few in number and vital for the functioning of the Tor network; threats of denial of service attacks against them have occurred in the past. They should be more resistant to unreasonably large connection volumes. 2. Design overview There are two possible ways a new connection to a directory authority can be established, directly by a TCP connection to the DirPort, or tunneled inside a Tor circuit and initiated with a begindir cell. The client can originate the former as direct connections or from a Tor exit, and the latter either as fully anonymized circuits or one-hop links to the dirauth's ORPort. The dirauth will try to heuristically classify incoming requests as one of these four indirection types, and then in the two non-anonymized cases further sort them into hash buckets on the basis of source IP. It will use an exponentially-weighted moving average to measure the rate of connection attempts in each bucket, and also separately limit the number of begindir cells permitted on each circuit. It will periodically scan the hash tables and forget counters which have fallen below a threshold to prevent memory exhaustion. 3. Classification of incoming connections Clients can originate connections as one of four indirection types: - DIRIND_ONEHOP: begindir cell on a single-hop Tor circuit - DIRIND_ANONYMOUS: begindir cell on a fully anonymized Tor circuit - DIRIND_DIRECT_CONN: direct TCP connection to dirport - DIRIND_ANON_DIRPORT: TCP connection to dirport from an exit relay The directory authority can always tell a dirport connection from a begindir, but it must use its knowledge of the current consensus and exit policies to disambiguate whether the connection is anonymized. It should treat a begindir as DIRIND_ANONYMOUS when the previous hop in the circuit it appears on is in the current consensus, and as DIRIND_ONEHOP otherwise; it should treat a dirport connection as DIRIND_ANON_DIRPORT if the source address appears in the consensus and allows exits to the dirport in question, or as DIRIND_DIRECT_CONN otherwise. In the case of relays which also act as clients, these heuristics may falsely classify direct/onehop connections as anonymous, but will never falsely classify anonymous connections as direct/onehop. 4. Exponentially-weighted moving average counters and hash table The directory authority implements a set of exponentially-weighted moving averages to measure the rate of incoming connections in each bucket. The two anonymous connection types are each a single bucket, but the two non- anonymous cases get a single bucket per source IP each, stored in a hash table. The directory authority must periodically scan this hash table for counters which have decayed close to zero and free them to avoid permitting memory exhaustion. This introduces five new configuration parameters: - DirDoSFilterEWMATimeConstant: the time for an EWMA counter to decay by a factor of 1/e, in seconds. - DirDoSFilterMaxAnonConnectRate: the threshold to trigger the DoS filter on DIRIND_ANONYMOUS connections. - DirDoSFilterMaxAnonDirportConnectRate: the threshold to trigger the DoS filter on DIRIND_ANON_DIRPORT connections. - DirDoSFilterMaxBegindirRatePerIP: the threshold per source IP to trigger the DoS filter on DIRIND_ONEHOP connections. - DirDoSFilterMaxDirectConnRatePerIP: the threshold per source IP to trigger the DoS filter on DIRIND_DIRECT_CONN connections. When incrementing a counter would put it over the relevant threshold, the filter is said to be triggered. In this case, the directory authority does not update the counter, but instead suppresses the incoming request. In the DIRIND_ONEHOP and DIRIND_ANONYMOUS cases, the directory authority must kill the circuit rather than merely refusing the request, to prevent an unending stream of client retries on the same circuit. 5. Begindir cap Directory authorities limit the number of begindir cells permitted in the lifetime of a particular circuit, separately from the EWMA counters. This can only affect the DIRIND_ANONYMOUS and DIRIND_ONEHOP connetion types. A sixth configuration variable, DirDoSFilterMaxBegindirPerCircuit, controls this feature. 6. Limitations Widely distributed DoS attacks with many source IPs may still be able to avoid raising any single DIRIND_ONEHOP or DIRIND_DIRECT_CONN counter above threshold.

2 1

[proposal] New Entry Guard Selection Algorithm
by isis 06 Nov '15

06 Nov '15

Hello, For your reviewing pleasure, may I present you with a new (draft) proposal for a new entry guard selection algorithm, and associated data structures (with reference implementations!). [0] The bulk of it is based upon George Kadianakis' recent email and pseudocode. [1] [2] There are still a few XXXs which need elucidation and/or comment. Relevant tickets include: https://bugs.torproject.org/17261 https://bugs.torproject.org/17262 https://bugs.torproject.org/16120 https://bugs.torproject.org/12466 https://bugs.torproject.org/12450 https://bugs.torproject.org/12595 Assistance with the completion of #17262 (due 31 Oct) would be greatly appreciated, since my plan for tomorrow is to work with some of the cryptographers here to review my changes to the crypto in rBridge for #7520. [0]: https://gitweb.torproject.org/user/isis/torspec.git/commit/?h=bug17261-best… [1]: https://lists.torproject.org/pipermail/tor-dev/2015-August/009328.html [2]: https://gitweb.torproject.org/user/asn/tor.git/tree/src/or/guardlist.c?h=bu… Best regards, -- ♥Ⓐ isis agora lovecruft _________________________________________________________ OpenPGP: 4096R/0A6A58A14B5946ABDE18E207A3ADB67A2CDB8B35 Current Keys: https://blog.patternsinthevoid.net/isis.txt

4 3

UX tag
by Nima Fatemi 03 Nov '15

03 Nov '15

Hello devs, May I encourage you to add "UX" tag (keyword) to the tickets you're filing or working on that are related to usability in any ways? This is to get a sense of how many tickets and what workload is related to usability in tor-related products. So I want to humbly ask you to use the tag regardless of the help you may or may not need for that ticket. And if you've any suggestions/ideas to measure this better, this is a great time to talk about it :) Peace ✌ -- Nima 0XC009DB191C92A77B | @mrphs "I disapprove of what you say, but I will defend to the death your right to say it" --Evelyn Beatrice Hall

4 4

Re: [tor-dev] Update of prop#250: Random Number Generation During Tor Voting
by Jesse V 02 Nov '15

02 Nov '15

David, I'm in the midst of reworking my OnioNS design around prop250 (and the security analysis therein) and as far as I can tell these changes make sense. I like the 00:00 -> 24:00 change as it's more intuitive as you said. I was at first very concerned that you removed the majority requirement as that is the assumption made during consensus generation, but I think your argument for the new conflict resolution make sense. I'm excited that the implementation is nearly complete and I look forward to seeing it in Tor infrastructure! Jesse V. On 10/28/2015 10:26 AM, David Goulet wrote: > First, period have been changed from 12:00 -> 12:00 (24 hour) to 00:00 > -> 24:00 so the protocol run is not over two days. Seemed more logical > and less confusing :). > > Second, we've removed the need of having majority for a commit to be > considered for the shared random computation. Yes this sounds intense!! > so it needs your attention.

3 2

Pluggable Transports v1 spec rewrite.
by Yawning Angel 31 Oct '15

31 Oct '15

Hello all, In an attempt to make Pluggable Transports more accessible to other people, and to have a spec that is more applicable and useful to other projects that seek to use Pluggable Transports for circumvention, I have drafted a re-write of the spec. This is not intended to alter existing behavior, but instead make it clear that the whole "Pluggable Transports" thing isn't just for Tor. Unless people have serious objections, this will replace the existing PT spec, to serve as a stop-gap while the next revision of the PT spec (that does alter behavior) is being drafted/implemented. Regards, -- Yawning Angel

3 3

Bridge Guards (prop#188) & Bridge ORPort Reachability Tests
by isis 30 Oct '15

30 Oct '15

Hey all, I have a working implementation of proposal #188, [0] which specifies a mechanism by which tor's (rather accidental) loose-source routing feature is utilised by Bridges in order to transparently inject a Bridge Guard into all client circuits. (See #7144. [1]) Currently, I am updating the text in proposal #188 to match my implementation, and I am trying to decide what to do about the two types of Bridge ORPort reachability testing. Here's the text I've written so far to explain the issues: (In the following, "Alice" is an OP, "Bob" is a Bridge, "Guillaume" is Bob's chosen Entry Guard, and "Charlie" is a random Middle node.) > 4.4. Bridge Reachability Testing > > Currently, a Bridge's reachability is tested both by the Bridge > itself (called "self-testing") and by the BridgeAuthority. > > 4.4.1. Bridge Reachability Self-Testing > > Before a Bridge uploads its descriptors to the BridgeAuthority, it > creates a special type of testing circuit which ends at itself: > > Bob -> Guillaume -> Charlie -> Bob > > Thus, going to all this trouble to later use loose-source routing in > order to relay Alice's traffic through Guillaume (rather than > connecting directly to Charlie, as Alice intended) is diminished by > the fact that Charlie can still passively enumerate Bridges by > waiting to be asked to connect to a node which is not > contained within the consensus. > > We could get around this option by disabling self-testing for bridges > entirely, by automatically setting "AssumeReachable 1" for all Bridge > relays… although I am not sure if this is wise. > > 4.4.2. Bridge Reachability Testing by the BridgeAuthority > > After receiving Bob's descriptors, the BridgeAuthority attempts to > connect to Bob's ORPort by making a direct TLS connection to the > Bridge's advertised ORPort. > > Should we change this behaviour? One the one hand, at least this > does not enable any random OR in the entire network to enumerate > Bridges. On the other hand, any adversary who can observe packets > from the BridgeAuthority is capable of enumeration. So, my current questions are: 1. Bridges only do reachability self-testing in order to warn their operators that the Bridge (or firewall or whatever) might be misconfigured, correct? Is there any other reason (or future reason) why self-testing is important/useful? 2. How should the self-testing be changed? 2.a. First, if there aren't any other reasons for self-testing: Is Bridge reachability self-testing actually helpful to Bridge operators in practice? Don't most Bridge operators just try to connect, as a client, to their own Bridge to see if it's working correctly? (This is what I usually do, at least…) If it's not useful to most Bridge operators, can we just disable self-testing for all Bridges? (And, should we disable it only for Bridges who are using Bridge Guards, or all of Bridges regardless?) 2.b. If it is useful to people, then the best way I can think of so far to keep it, but refactor it to be safer, would be to create a circuit like: Bridge → Guard → Middle → OtherMiddle → Guard → Bridge Clearly, that circuit is just a little bit insane… but we can't do: Bridge → Guard → Middle → Guard → Bridge because the Middle would refuse to extend back to the previous node (all ORs follow this rule). Similarly, it would be stupid to do: Bridge → Guard → Middle → OtherMiddle → Bridge because, obviously, that merely shifts the problem and accomplishes nothing. But is there something smarter I could do? 3. Should we change how the BridgeAuthority tests Bridge ORPort reachability? If so, how? 4. If I'm going to refactor all of this, are there other (future) things I should take into account? For example, if self-testing is disabled for Bridges, and, due to #7349, [2] the BridgeAuthority isn't testing reachability either, then how will the BridgeAuthority know if (any of) the Bridge's PTs are reachable? (One solution might be to, in that case, have the BridgeAuthority lie and tell BridgeDB that such Bridges were reachable, letting BridgeDB do the PT reachability testing.) Please help me brainstorm a way out of this mess! [0]: https://gitweb.torproject.org/torspec.git/tree/proposals/188-bridge-guards.… [1]: https://bugs.torproject.org/7144 [2]: https://bugs.torproject.org/7349 Best Regards, -- ♥Ⓐ isis agora lovecruft _________________________________________________________ OpenPGP: 4096R/0A6A58A14B5946ABDE18E207A3ADB67A2CDB8B35 Current Keys: https://blog.patternsinthevoid.net/isis.txt

4 8

Tor Messenger Beta: Chat over Tor, Easily
by Sukhbir Singh 30 Oct '15

30 Oct '15

Hi, Today we are releasing a new, beta version of Tor Messenger, based on Instantbird [0], an instant messaging client developed in the Mozilla community. * What is it? Tor Messenger is a cross-platform chat program that aims to be secure by default and sends all of its traffic over Tor. It supports a wide variety of transport networks, including Jabber (XMPP), IRC, Google Talk, Facebook Chat, Twitter, Yahoo, and others; enables Off-the-Record (OTR) Messaging [1] automatically; and has an easy-to-use graphical user interface localized into multiple languages. * What it isn't... Tor Messenger builds on the networks you are familiar with, so that you can continue communicating in a way your contacts are willing and able to do. This has traditionally been in a client-server model, meaning that your metadata (specifically the relationships between contacts) can be logged by the server. However, your route to the server will be hidden because you are communicating over Tor. We are also excited about systems like Pond [2] and Ricochet [3], which try to solve this problem, and would encourage you to look at their designs and use them too. * Why Instantbird? We considered a number of messaging clients: Pidgin, Adam Langley's xmpp-client, and Instantbird. Instantbird was the pragmatic choice -- its transport protocols are written in a memory-safe language (JavaScript); it has a graphical user interface and already supports many natural languages; and it's a XUL application, which means we can leverage both the code (Tor Launcher) and in-house expertise that the Tor Project has developed working on Tor Browser with Firefox. It also has an active and vibrant software developer community that has been very responsive and understanding of our needs. The main feature it lacked was OTR support, which we have implemented [4] and hope to upstream to the main Instantbird repository for the benefit of all Instantbird (and Thunderbird) users. * Current Status Today we are releasing a beta version with which we hope to gain both usability and security related feedback. There have been three previous alpha releases to the mailing lists that have already helped smooth out some of the rougher edges. * Downloads Linux (32-bit) https://dist.torproject.org/tormessenger/0.1.0b2/tor-messenger-linux32-0.1.… Linux (64-bit) https://dist.torproject.org/tormessenger/0.1.0b2/tor-messenger-linux64-0.1.… Windows https://dist.torproject.org/tormessenger/0.1.0b2/tormessenger-install-0.1.0… OS X https://dist.torproject.org/tormessenger/0.1.0b2/TorMessenger-0.1.0b2-osx64… sha256sums https://dist.torproject.org/tormessenger/0.1.0b2/sha256sums.txt https://dist.torproject.org/tormessenger/0.1.0b2/sha256sums.txt.asc The sha256sums.txt file containing hashes of the bundles is signed with the key 0x6887935AB297B391 (fingerprint: 3A0B 3D84 3708 9613 6B84 5E82 6887 935A B297 B391). * Instructions - On Linux, extract the bundle(s) and then run: ./start-tor-messenger.desktop - On OS X, copy the Tor Messenger application from the disk image to your local disk before running it. On all platforms, Tor Messenger sets the profile folder for Firefox/Instantbird to the installation directory. - Note that as a policy, unencrypted one-to-one conversations are not allowed and your messages will not be transmitted if the person you are talking with does not have an OTR-enabled client. You can disable this option in the preferences to allow unencrypted communication but doing so is not recommended. * Source Code We are doing automated builds [5] of Tor Messenger for all platforms. The Linux builds are reproducible: anyone who builds Tor Messenger for Linux should have byte-for-byte identical binaries compared with other builds from a given source. You can build it yourself [6] and let us know if you encounter any problems or cannot match our build. The Windows and OS X builds are not completely reproducible yet but we are working on it [7]. * What's to Come Our current focus is security, robustness and user experience. We will be fixing bugs and releasing updates as appropriate, and in the future, we plan on pairing releases with Mozilla's Extended Support Release (ESR) cycle. We have some ideas on where to take Tor Messenger but we would like to hear what you have to say. Some possibilities include: - Reproducible builds for Windows and OS X (#10942) - Sandboxing (#10943) - Automatic updates (#14388) - Improved Tor support (#10950) - OTR over Twitter DMs (#13312) - Produce (and distribute) internationalized builds (#10945) - Secure multi-party communication (np1sec) [8] - Encrypted file-transfers - Usability study * How To Help Give it a try and provide feedback, requests, and file bugs [9] (choose the "Tor Messenger" component). If you are a developer, help us close all our tickets [10] or help us review our design doc [11]. As always, we are idling on IRC in #tor-dev (OFTC) (nicks: arlolra; boklm; sukhe) and subscribed to the tor-talk/dev mailing lists. Please note that this release is for users who would like to help us with testing the product but at the same time who also understand the risks involved in using beta software. Thanks and we hope you enjoy Tor Messenger! [0] - http://instantbird.com [1] - https://otr.cypherpunks.ca [2] - https://pond.imperialviolet.org [3] - https://ricochet.im [4] - https://github.com/arlolra/ctypes-otr [5] - https://gitweb.torproject.org/tor-messenger-build.git [6] - https://gitweb.torproject.org/tor-messenger-build.git/tree/README [7] - https://trac.torproject.org/projects/tor/ticket/10942 [8] - https://github.com/equalitie/np1sec [9] - https://trac.torproject.org/projects/tor/newticket [10] - https://trac.torproject.org/projects/tor/query?status=!closed&component=Tor… [11] - https://trac.torproject.org/projects/tor/wiki/doc/TorMessenger/DesignDoc

2 3

[Applications Team] First meeting next Tuesday 19:00 UTC
by Georg Koppen 30 Oct '15

30 Oct '15

Hi, just a reminder that the applications team is starting the monthly meetings next week on Tuesday, November 3 at 19:00 UTC[0] in #tor-project on irc.oftc.net. The proposed topic is still talking about UX/internationalization issues. If there are other things worth discussing we can easily amend the agenda at the beginning of the meeting. See you there, Georg [0] Originally I had written "18:00 UTC" but I forgot to take the end of the summer time into account.

1 0

Re: [tor-dev] Pluggable Transports v1 spec rewrite.
by Nathan Freitas 29 Oct '15

29 Oct '15

On Thu, Oct 29, 2015, at 09:19 AM, Yawning Angel wrote: > Hello all, > > In an attempt to make Pluggable Transports more accessible to other > people, and to have a spec that is more applicable and useful to other > projects that seek to use Pluggable Transports for circumvention, I have > drafted a re-write of the spec. > > This is not intended to alter existing behavior, but instead make it > clear that the whole "Pluggable Transports" thing isn't just for Tor. > > Unless people have serious objections, this will replace the existing > PT spec, to serve as a stop-gap while the next revision of the PT spec > (that does alter behavior) is being drafted/implemented. > Any small or big changes to highlight that push us to the more accessible goal?

2 1