- tor-dev - lists.torproject.org

Bandwidth Weighted Node selection algorithm
by saurav dahal 29 Aug '14

29 Aug '14

Hello, In the paper, "Zhen Ling; Junzhou Luo; Wei Yu; Ming Yang; Xinwen Fu, "Extensive analysis and large-scale empirical evaluation of tor bridge discovery," *INFOCOM, 2012 Proceedings IEEE* , vol., no., pp.2381,2389, 25-30 March 2012", the author has mentioned about Bandwidth Weighted Node selection algorithm. He has mentioned about bandwidth weights WG and WE, responsible for node selection. But in the Tor directory protocol version 3, there is no such mention of these weights but rather there are other weights such as Wgg, Wee, etc. Can anybody please elaborate on this? Thanks, -- Saurav

2 2

Prototype Primitives for Website Traffic Fingerprinting defenses
by Mike Perry 28 Aug '14

28 Aug '14

Hello all, What follows is a summary of the primitives that Marc Juarez aims to implement for his Google Summer of Code project on prototyping defenses for Website Traffic Fingerprinting and follow-on research. After a review of Tamaraw[1], Adaptive Padding[2], CS-BuFLO[3], and the Supersequence[4] work, as well as some discussion at the Tor dev meeting, we came up with this list of padding message primitives. These functions are meant to be sent as command cells from one endpoint to the other. Some are bidirectional commands, others can only be sent in one direction (client to relay, or relay to client). For now, they will be implemented as ad-hoc messages between two modified obfsproxy (called wfpadtools) instances. The source code for this fork lives here for the moment: https://bitbucket.org/mjuarezm/obfsproxy-wfpadtools/ Long term, I am thinking that all of these should be specified as if they were their own RELAY_* cell type from tor-spec.txt: https://gitweb.torproject.org/torspec.git/blob/HEAD:/tor-spec.txt#l1215 This means that padding would be a circuit-level property, and it would be possible to send it to and from any hop in the circuit, due to leaky-pipe topology (using the "recognized" field). In a world of very cheap and excessive middle and Guard node bandwidth, we would run this padding to the middle node. For the wfpadtools prototype, it will obviously only cover the first hop. Here's the list of primitives, broken down by research paper: Generic Messages (common to all defenses): RELAY_IGNORE() Description: Simple fixed-length (CELL_SIZE) padding cell. Direction: Bidirectional (client to relay, relay to client) Parameters: None RELAY_SEND_PADDING(N,t) Description: Send the requested number of padding cells in response. Direction: Client to relay Parameters: N: Number of padding cells to send in response to this cell t: microseconds delay before sending RELAY_APP_HINT(session_id, status) Description: A hint from the application layer for session start/stop Direction: Client to relay Parameters: session_id: A string identifying the session (ie keyed hash of url bar domain) status: "Start" or "Stop", indicating session start and end. Adaptive Padding Messages: RELAY_BURST_HISTOGRAM(histogram[], labels_ms[], remove_toks, fuzz, when) Description: Specifies a histogram that encodes a delay distribution representing the probability of sending a single padding packet after a given delay in response to either an upstream cell, or a client-originating cell. Direction: Client to relay Parameters: histogram[]: Contains delay distribution of sending an IGNORE packet after sending a real packet labels_ms[]: millisecond labels for the bins (with "Infinity"/"Ignore" bin to allow encoding the probability of not sending any padding packet in response to this packet). remove_toks: If true, follow Adaptive Padding token removal rules. If false, histograms are immutable. fuzz: If true, randomize the delay uniformly between bin labels. If false, use bin lables as exact delay values. when: If set to "receive", this histogram governs the probably of sending a padding packet after some delay in response to a packet originating from. If set to "send", this histogram governs padding packets that are transmitted after a packet arrives from upstream (the middle node). In both cases, the padding packet is sent in the direction of the client. RELAY_GAP_HISTOGRAM(histogram[], labels_ms[], remove_toks, fuzz, when) Description: Specifies a histogram that encodes a delay distribution representing the probability of sending a single additional padding packet after a given delay following a padding packet that originated at this hop. Direction: Client to relay Parameters: histogram[]: Contains delay distribution of sending an IGNORE packet after sending an IGNORE packet labels_ms[]: millisecond labels for the bins (with "Infinity"/"Ignore" bin to allow encoding the probability of not sending any padding packet in response to this packet). remove_toks: If true, follow Adaptive Padding token removal rules. If false, histograms are immutable. fuzz: If true, randomize the delay uniformly between bin labels. If false, use bin lables as exact delay values. when: If "receive", this histogram applies to locally-inserted padding packets that were initially sent in response to client-originated data. If "send", this histogram applies to packets sent in response to locally-inserted padding packets sent in response to upstream data. Note that this means that implementations must maintain this metadata as internal state as the system transitions from BURST_HISTOGRAM initiated padding into GAP_HISTOGRAM initiated padding. In both cases, the padding packet is sent in the direction of the client. CS-BuFLO Messages: RELAY_TOTAL_PAD(session_id, t): Description: Requests that endpoint pad all batches to nearest 2^K cells total or until APP_HINT(session_id, stop) Direction: Client to relay Parameters: session_id: The session ID from APP_HINT() t: The number of microseconds to wait between cells to consider them part of the same batch. RELAY_PAYLOAD_PAD(session_id, t, R): XXX: The paper was not clear enough for me to understand this primitive Tamaraw: RELAY_BATCH_PAD(session_id, L, t) Description: Requests that endpoint pad all batches of cells to L cells total or until APP_HINT(session_id, stop) Direction: Client to relay Parameters: session_id: The session ID from APP_HINT() L: The multiple of cells to pad to. t: The number of microseconds to wait between cells to consider them part of the same batch. Comments, questions, and suggestions are welcome! In particular, I'm not sure I got either the CS-Buflo or the tamaraw primitives completely correct. 1. http://cacr.uwaterloo.ca/techreports/2013/cacr2013-30.pdf 2. http://freehaven.net/anonbib/cache/ShWa-Timing06.pdf 3. http://arxiv.org/abs/1401.6022 4. http://cacr.uwaterloo.ca/techreports/2014/cacr2014-05.pdf -- Mike Perry

1 2

Tor Data Leak
by sureyourejoking＠aim.com 28 Aug '14

28 Aug '14

To Whom it May Concern, I recently noticed that Tor Browser was leaking data about websites I visited in Tor to my hard drive. I am running Mac OS X 10.6.8 on a 2010 model Macbook Pro 6,2. I am using TorBrowser Version 3.6.3. The data appears in the directory "/Users/Username/Library/PubSub/Feeds/", where "Username" represents my username. The directory contains xml files with random names and a .xml extension. They contain text and url's from websites which I have only visited using Tor. I use "No-Script" in Tor, and it is active by default. "No-Script" was active when I visited all of the websites, except for youtube, since the videos will not play while "No-Script" is active. I have installed the following add-ons to Tor: "Adblock Edge 2.1.4" and "Privacy Badger Firefox 0.2.1". I noticed these xml files a month ago, and moved the contents of /Users/Username/Library/PubSub/ to a separate location. Since then, I have watched the contents of this directory closely. Two days after I deleted the contents of "PubSub", a directory called "Database" appeared containing a file called "Database.sqlite3". This file seemed not to have any information about websites I visited. A while later, the "Feeds" directory appeared, but was empty. The "Feeds" directory remained empty for about two weeks. Yesterday, xml files appeared in the Feeds directory, which now contains 1.1 MB of files. Is this a security bug in Tor Browser?

2 1

[RELEASE] Torsocks 2.0.0 stable
by David Goulet 25 Aug '14

25 Aug '14

Hi everyone! Following the discussion of bug #10007[1], this is the *stable* release 2.0.0 for torsocks. Nothing major went in since -rc7, see the change log below. 2014-08-11 torsocks 2.0.0 * Fix: compilation issue on Debian kfreebsd-i386 * Fix: add LICENSE file to repository * Fix: add compilation requirements to README.md Again, as usual, and forever! *please* code review, test and most importantly report any issues. Contribution ftw! :) Thanks to everyone! Git: https://gitweb.torproject.org/torsocks.git Tarball: https://people.torproject.org/~dgoulet/torsocks/torsocks-2.0.0.tar.bz2 (sig: https://people.torproject.org/~dgoulet/torsocks/torsocks-2.0.0.tar.bz2.asc) Cheers! David [1] https://trac.torproject.org/projects/tor/ticket/10007

2 1

Call for testing/review: obfsclient-0.0.1
by Yawning Angel 25 Aug '14

25 Aug '14

Hello all, I just tagged the obfsclient v0.0.1 (Release) Download at: https://github.com/Yawning/obfsclient/releases/tag/v0.0.1 Major changes since 0.0.1-rc2: * Invalid padding lengths in obfs3/ScrambleSuit handshakes are now correctly handled. * Handshake timeout is now set to a random interval between 60 and 120 seconds. * The ScrambleSuit probability distributions are now closer to what obfsproxy generates. * "--version" will now cause obfsclient to print the version and exit. * Various code cleanups. Some notes about ScrambleSuit: * I reverted the "workaround" I had for bug #11100, so Session Ticket handshakes to bridges running obfsproxy 0.2.6 will fail if they have been running long enough to trigger the bug condition. * Actual protocol behavior is closer to obfsproxy than my previous releases, but still not identical to 0.2.7. the next obfsproxy release will close the difference further. Hopefully it is of some use to people. Special thanks to Fabian Keil for help testing and fixing the various release candidates. Questions, comments, feedback appreciated as always, -- Yawning Angel

2 4

Damian's Status Report - August 2014
by Damian Johnson 24 Aug '14

24 Aug '14

Hi all, getting my status report out of the way a tad early. Deadlines for my day job at Amazon required working a weekend so April was mostly spent just getting caught up on code reviewing contributions... * Nick Mathewson greatly improved Stem's performance at parsing consensus documents. Thanks Nick! (#12859) * Rewrote Nick Hopper's patch for verifying consensus signatures. I'd really love to merge it, but it needs tests first. (#11045) * Code reviewed federico3's addition of better Controller methods for handling hidden service config options. (#12533) * Fixed stylistic issues cited by the newly released pep8 1.5.7, and also corrected a handful of python 3.x test failures. * Code reviewed a BridgeDB change to take advantage of Stem for isis. (#9380) * GSoC finals are finished! This year had a lower pass rate than we usually do (four of our thirteen students didn't pass), but I don't think there's necessarily any lessons to draw. This concludes my backlog of things I owe other people, so next up I'll finally be getting back to arm development! -Damian

1 0

[GSoC] Consensus diffs - Sixth report
by Daniel Martí 24 Aug '14

24 Aug '14

Hello everyone, This is the sixth and last status report of my Google Summer of Code project, which is to implement consensus diffs for Tor. Two weeks ago I had two main tasks left for the project to get to a minimal functioning state. The first was to figure out a clean way to cache old consensuses on disk. The second was to write the fetching of consensus diffs, and the corresponding serving of consensus diffs via spooling. Both of these were done, and last week I was able to launch a small local network via chutney and finally see consensus diffs be properly generated, served, fetched and applied. The hard pencils down date is tomorrow evening. I want to polish things up a bit and try to find last-minute bugs. Of course there will be quite a bit of work left once GSoC is over to get the outcome of this project included in Tor. Other than that, I'm quite happy with how the project turned out. I intend to continue contributing to Tor, at least to the extent of getting the code merged into master and fixing any bugs that may arise until it is suitable for a stable release. I'll continue pushing my work on Github [1] for now. See the "readme" branch for reference on what the consdiff-N branches mean. Regards. [1] https://github.com/mvdan/tor -- Daniel Martí - mvdan(a)mvdan.cc - http://mvdan.cc/ PGP: A9DA 13CD F7A1 4ACD D3DE E530 F4CA FFDB 4348 041C

3 2

Reminder: OONI dev meetings Friday 15:00 UTC (17:00 CET)
by Arturo Filastò 21 Aug '14

21 Aug '14

Hello Oonitarians, This is a reminder that the weekly dev meeting will be happening on the #ooni channel on irc.oftc.net this Friday (tomorrow and every following Friday) at 15:00 UTC (17:00 CET). Everyone is invited. ~ Art.

1 0

Fwd: [guardian-dev] Orfox: New Firefox-based Android Private/Secure Browser
by Nathan Freitas 21 Aug '14

21 Aug '14

Nice outcome from GSoC! I think the primary discussion here is whether Tor Browser's existing build system can be extended for Android, and whether "Orfox" should exist at all as separate app/project. -------- Forwarded Message -------- Subject: [guardian-dev] Orfox: New Firefox-based Android Private/Secure Browser Date: Wed, 20 Aug 2014 12:49:33 -0400 From: Nathan of Guardian <nathan(a)guardianproject.info> Organization: The Guardian Project To: guardian-dev <guardian-dev(a)lists.mayfirst.org> Based on work done this summer by Amogh Pradeep during his Google Summer of Code stint with me, we now have a real working version of Firefox/Fennec for Android with all the necessary defaults changed to match Tor Browser's defaults as closely as possible. We also remove the Android permissions for things like camera, mic, GPS and turn off webrtc. You can see the primary commits we've made here (many by me, but started successfully by Amogh): https://github.com/guardianproject/gecko-dev/commits/adaa37949dbba690ed0392… We still need to figure out which preferences and features map between the desktop mobile browser and the Android version, so there is quite a bit of work to do. For instance, even though the preference from Tor Browser is set to start in private browsing mode, it doesn't work at all in the Android app. Also, we haven't applied any of the lower level source patches to the gecko engine yet, or included any of the default extensions like HTTPS Everywhere or NoScript. Sorting out and resolving these differences is what is on deck for this fall, and everyone is welcome to join in. In addition, the recent audit work from iSec (https://blog.torproject.org/blog/isec-partners-conducts-tor-browser-hardeni…) is also on our minds, and figuring out how we can live up to the goals of that study on a mobile device is also very important. The current build successfully passes the DNSLeakTest.com tests and passed the HTML5 video leak issue here: http://xordern.net/why-you-really-shouldn't-use-orweb-anymore.html ip-check.info still doesn't see the browser as being Tor Browser, so there are some differences yet to resolve there. The whole project is automatically building on our jenkins server, and you'll find all the links to APKs and our test build repo below. Over the next few months we hope to launch this as our new official browser for Orbot, and deprecate Orweb as quickly as possible. *** Main project repo: https://github.com/guardianproject/OrfoxFennec Our fork of Mozilla's Gecko-Dev: https://github.com/guardianproject/gecko-dev/tree/adaa37949dbba690ed0392c1f… (which we can rebase on the original as needed) Nightly/dev builds direct APK download here: https://guardianproject.info/builds/OrfoxFennec/ OR our fdroid test build repo: https://dev.guardianproject.info/fdroid/repo?fingerprint=F8ED4C73C125E7A67F… *** +n _______________________________________________ Guardian-dev mailing list Post: Guardian-dev(a)lists.mayfirst.org List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev To Unsubscribe Send email to: Guardian-dev-unsubscribe(a)lists.mayfirst.org Or visit: https://lists.mayfirst.org/mailman/options/guardian-dev/nathan%40guardianpr… You are subscribed as: nathan(a)guardianproject.info

3 5

GSoC : Rewrite Tor Weather (Status Update 6)
by Sreenatha Bhatlapenumarthi 19 Aug '14

19 Aug '14

Hey folks! This is my 6th and final GSoC status update on the Weather-Rewrite project. Things I worked on since my last update : - Wrote a small python script to clear the subscription data stored in the django models of the weather database before running the standalone scripts. This is particularly useful while testing the site. - Fixed some bugs in the daily script. - Tested the whole thing after removal of the consensus event-listener mechanism with file-based SMTP backend as well as gmail SMTP server with a test email setup. - Modified the standalone daily/hourly scripts to work as custom django management commands as suggested in #10706. - Updated documentation regarding the shift in data backend to Onionoo. - Style-aligned the code base with PEP8. To review the code, check out https://github.com/meejah/tor-weather/tree/develop As a note on collaborating with the Tor community during this summer through GSoC, I want to mention that I had great time with this and will try to keep making meaningful contributions via various development activities. Thank You for the experience. Cheers, Sreenatha

1 0

ooniprobe 1.1.0 is out!
by Arturo Filastò 19 Aug '14

19 Aug '14

Hello beautiful humans! We are very pleased to announce that a new version of ooniprobe is now out. In this new release of ooniprobe we have added a new command line tool for listing the reports that have not been published to a collector and that allows the probe operator to choose which ones they would like to upload. We have also made some privacy improvements to the reports (we will sanitize all things that may look like file paths) and added metadata associated with the maxmind database being used by the probe operator. Here is a more detailed list of what has been done: * Annotate on disk which reports we have submitted and which ones we have not: https://trac.torproject.org/projects/tor/ticket/11860 * Add tool called oonireport for publishing unpublished ooniprobe reports to a collector: https://trac.torproject.org/projects/tor/ticket/11862 * Probe Report does not leak filepaths anymore: https://trac.torproject.org/projects/tor/ticket/12706 * Reports now include version information about the maxmind database being used: https://trac.torproject.org/projects/tor/ticket/12771 * We now do integrity checks on the ooniprobe.conf file so that we don't start the tool if the config file is missing some settings or is not consistent: https://trac.torproject.org/projects/tor/ticket/11983 (thanks to Alejandro López (kudrom)) * Improvements have been made to the sniffer subsystem (thanks to Alejandro López (kudrom)) * Fix the multi protocol traceroute test. https://trac.torproject.org/projects/tor/ticket/12883 Minor bug fixes: * Fix dns_spoof test (by kudrom) https://trac.torproject.org/projects/tor/ticket/12486 * ooni might not look at requiresTor: https://trac.torproject.org/projects/tor/ticket/11858 * ooni spits out gobs of tracebacks if Tor is not running and the OONI config says it will be: https://trac.torproject.org/projects/tor/ticket/11859 * The README for ooni-probe should mention the bugtracker and repository https://trac.torproject.org/projects/tor/ticket/11980 For the moment you can download the new version from pypi here: https://pypi.python.org/pypi/ooniprobe. Soon a there will also be a new debian package for it (thank to Lunar^). As always feedback is greatly appreciated so please submit any bugs you may find to our bug tracker: https://trac.torproject.org/projects/tor/newticket?component=Ooni Have fun! ~ Art.

1 0

Re: [tor-dev] Proposal: All Relays are Directory Servers
by Tim 19 Aug '14

19 Aug '14

On 19 Aug 2014, at 22:00 , tor-dev-request(a)lists.torproject.org wrote: > Date: Tue, 19 Aug 2014 01:32:25 +0000 > From: Matthew Finkel <matthew.finkel(a)gmail.com> > To: tor-dev(a)lists.torproject.org > Subject: Re: [tor-dev] Proposal: All Relays are Directory Servers > Message-ID: <20140819013224.GB3689@localhost> > Content-Type: text/plain; charset=utf-8 > > On Mon, Aug 18, 2014 at 02:17:28PM -0400, Nick Mathewson wrote: >> On Wed, Aug 13, 2014 at 11:53 AM, Matthew Finkel >> <matthew.finkel(a)gmail.com> wrote: > >>> Filename: xxx-directory-servers-for-all.txt >>> Title: All relays are directory servers >>> Author: Matthew Finkel >>> Created: 29-Jul-2014 >>> Status: >>> Target: 0.2.6.x >>> >>> Overview: >>> >>> This proposal aims at removing part of the distinction between the >>> relay and the directory server. Currently operators have the options >>> of being one of: a relay, a directory server, or both. With the >>> acceptance of this proposal the options will be simplified to being >>> either only a directory server or a combined relay and directory >>> server. All relays will serve directory requests. >> >> FWIW, we don't support being only a directory server right now, do we? >> > > Nope, you're right. Bad assumption. > > https://gitweb.torproject.org/tor.git/blob/390728d85644a6c062d6807ffc096343… Looking at the details of parse_ports(), the warning/comment isn't entirely accurate: it seems that any configured "port" is enough to disable the warning (even a DirPort, ControlPort/ControlSocket(!), or ExtORPort). Which is why I'm not seeing it on the directory-only tor instance I have configured. Then again, the core message is accurate - a tor instance that doesn't act as a tor client or relay isn't going to do much. Tim

1 0

Re: [tor-dev] Proposal: All Relays are Directory Servers
by Tim 19 Aug '14

19 Aug '14

> On 19 Aug 2014, at 11:30, Nick Mathewson <nickm(a)freehaven.net> wrote: > > Date: Mon, 18 Aug 2014 14:17:28 -0400 > From: Nick Mathewson <nickm(a)freehaven.net> > To: tor-dev(a)lists.torproject.org > Subject: Re: [tor-dev] Proposal: All Relays are Directory Servers > > >> On Wed, Aug 13, 2014 at 11:53 AM, Matthew Finkel >> <matthew.finkel(a)gmail.com> wrote: >> Hi All, >> >> Below is the proposal for #12538 [0], with some changes after George's >> review and some other revisions. >> >> Feedback welcome! >> >> Thanks, >> Matt >> >> >> [0] https://trac.torproject.org/projects/tor/ticket/12538 > > Thanks! This is now proposal 237. Any revisions should be sent in as > patches against the one in the torspec repository. > >> Filename: xxx-directory-servers-for-all.txt >> Title: All relays are directory servers >> Author: Matthew Finkel >> Created: 29-Jul-2014 >> Status: >> Target: 0.2.6.x >> >> Overview: >> >> This proposal aims at removing part of the distinction between the >> relay and the directory server. Currently operators have the options >> of being one of: a relay, a directory server, or both. With the >> acceptance of this proposal the options will be simplified to being >> either only a directory server or a combined relay and directory >> server. All relays will serve directory requests. > > FWIW, we don't support being only a directory server right now, do we? I've recently configured a tor instance [for HTTP fuzzing] that does nothing but cache the entire directory - all that is required is setting the DirPort non-zero, and the ORPort to 0. No warnings are emitted, and the instance stays stable, up to date with the consensus and descriptors, and answers [local] directory requests [as configured]. Because it's a local/test instance, I have specifically disabled external access. I have also disabled the default relay/directory server behaviour of submitting its own descriptor to the authorities. So I don't actually know if it would submit a descriptor if I enabled that option. However, the man page says that either one of a directory or a router port is sufficient for a server to submit its descriptor to the consensus. I also don't know if clients would connect to a directory server that didn't have an ORPort. Do clients select directory guards based on flags that it's impossible for a directory-only Tor instance to obtain? What about HSDirs? Nick, which of these things did you mean by "support"? Does the consensus include directory-only Tor servers? Do tor clients connect to directory-only Tor servers? Will a directory-only Tor server ever get the flags needed to become a "directory guard"? Will a directory-only Tor server ever get the flags needed to become a HSDir? (I think we agree that a directory-only server is a far less useful configuration of an instance than a router would be.) Tim

1 0

Proposal: All Relays are Directory Servers
by Matthew Finkel 19 Aug '14

19 Aug '14

Hi All, Below is the proposal for #12538 [0], with some changes after George's review and some other revisions. Feedback welcome! Thanks, Matt [0] https://trac.torproject.org/projects/tor/ticket/12538 ----------------------------------------------------------------------- Filename: xxx-directory-servers-for-all.txt Title: All relays are directory servers Author: Matthew Finkel Created: 29-Jul-2014 Status: Target: 0.2.6.x Overview: This proposal aims at removing part of the distinction between the relay and the directory server. Currently operators have the options of being one of: a relay, a directory server, or both. With the acceptance of this proposal the options will be simplified to being either only a directory server or a combined relay and directory server. All relays will serve directory requests. Motivation: Fetching directory documents and descriptors is sometimes a non-trivial operation for clients. If they do not have a consensus then they must contact a directory authority (until directory sources are added or clients are able to use a fallback consensus). If they have a consensus and have at least one entry guard then the client can query that guard for documents. If the document isn't available then after a period of time the client will attempt to retry downloading it. If the entry guard isn't a directory server, as well, a directory server and/or directory guard must be chosen (based on the server having an open DirPort) and queried for the document. At a minimum, this has a potential performance impact, at worst it's another attack vector that allows for profiling clients and partitioning users. With the orthogonally proposed move to clients using a single guard, the potential performance bottleneck and ability to profile users could be exacerbated. If the client selects an entry guard and it is not a directory server then the client may select a distinct directory guard which will leak client behavior to a second node. In the case where the client does not use guards, it is important to have the largest possible amount of diversity in the set of directory servers. In a network where every relay is a directory server, the profiling and partitioning attack vector is reduced to the guard (for clients who use them), which is already in a privileged position for this. In addition, with the increased set size relay descriptors and documents are more readily available and it diversifies the providers. Design: The changes needed to achieve this should be simple. Currently all relays download and cache the majority of relay documents in any case, so the slight increased memory usage from downloading all of them should have minimal consequences. There will be necessary logical changes in the client, router, and directory code. Currently directory servers are defined as such if they advertise having an open directory port. We can no longer assume this is true. To this end, we will introduce a new server descriptor line. "tunnelled-dir-server" NL The presence of this line indicates that the relay accepts tunnelled directory requests. For a relay that implements this proposal, this line MUST be added to its descriptor if it does not advertise a directory port, and MAY be added if it also advertises an open directory port. In addition to this, relays will now download and cache all descriptors and documents listed in the consensus, regardless of whether they are deemed useful or usable, exactly like the current directory servers. All relays will also accept directory requests when they are tunnelled over a connection established with a BEGIN_DIR cell, the same way these connections are already accepted by bridges and directory servers with an open DirPort. Directory Authorities will now assign the V2Dir flag to a server if it supports a version of the directory protocol which is useful to clients and it has at least an open directory port or it has an open and reachable OR port and advertises "tunnelled-dir-server" in its server descriptor. Clients choose a directory by using the current criteria with the additional criterion that a server only needs the V2Dir status flag instead of requiring an open DirPort. When the client chooses which directory server it will query, it checks if the server has an open directory port and uses begindir if it does not have one. Directory servers should not be able to determine which version of Tor the client is using (or a lower-bound on the version), if possible. Continuing to prefer direct directory connections over begin may help mitigate a potential partitioning attack. Security Considerations and Implications: Currently all directory servers are explicitly configured. This is necessary because they must have a configured and reachable external port. However, this is a restriction and results in a reduced number of directory servers on the network. As a result, this could allow an adversary to control a significant fraction of the servers. By increasing the number of directory servers on the network the likelihood of selecting one that is malicious is reduced. Also, with this proposal, it will be more likely that a client's entry guard is also a directory server (as alluded to in Proposal 207). However, the reduced anonymity set caused when the guard does not have, or is unwilling to distribute, a specific document still exists. With the increased diversity in the available servers, the impact of this should be reduced. Another question that may need further consideration is whether we trust bad directories to be good guards and exits. Specification: The version 3 directory protocol specification does not currently document the use of directory guards. This spec should be updated to mention the preferred use of directory guards during directory requests. In addition, the new criteria for assigning the V2Dir flag should be documented. Impact on local resources: Should relays attempt to download documents from another mirror before asking an authority? All relays will now prefer contacting the authorities first, but this will not scale well and will partition users from relays. If all relays become directory servers, they will choose to download all documents, regardless of whether they are useful, in case another client does want them. This will have very little impact on the "typical" relay, however on memory constrained relays (BeagleBone, Raspberry Pi, and similar), every megabyte allocated to directory documents is not available for new circuits. Should we add a config option that allows operators to disable being a directory server? Is it more worthwhile for them to serve these documents or to relay cells? Future Considerations: Should the DirPort be deprecated at some point in the future?

2 2

Final Fog Combiner GSoC Report and Fog Status/Description
by quinn jarrell 19 Aug '14

19 Aug '14

Hi all, This report is going to be a bit longer and more general than usual as it'll cover a lot more about the current state of Fog and a description of it. This is my last report for GSoC, but I will probably continue submitting patches to Fog. Here's a general description of what I worked on this summer. Fog provides an easy way to chain pluggable transports together. It allows users to obfuscate their Tor data in multiple layers by using the output of one pluggable transport as the input for another. This will hopefully make pluggable transports much more difficult to block and provide more anonymity for users. Fog has two components, a client written in Python and a server written in Go. It appears to Tor as a normal pluggable transport and acts like one. But instead of obfuscating the data itself like other pluggable transports, it proxies the data through other pluggable transports. It then receives the obfuscated data and passes it onto the next pluggable transport in the chain and so on. After the last pluggable transport obfuscates the data and sends it back to Fog, Fog sends it onto the bridge address where the Fog server is waiting. The Fog server works similarly, but reverses the order of the pluggable transports, allowing each pluggable transport to peel off a layer of obfuscation. When it completely deobfuscates the data after traveling through the chain in reverse, Fog sends the data onto Tor as if it is a normal pluggable transport. The nice part about Fog is that it requires very little if any modification of existing pluggable transports to create chains. As long as a pluggable transport talks obeys the PT-Spec[0] and sends its results to a prespecified server, it can be used. So for instance all the chains: b64|obfs3|scramblesuit, scramblesuit|fte|bananaphone|obfs3 will work without any modification of those pluggable transports. Now the exceptions to this are pluggable transports that send obfuscated data to different servers on every startup. This mainly includes the flash proxy and Meek pluggable transports. These can only be used currently at the end of a chain. The reason being that since they send to different servers every time, it is not possible to direct them to a SOCKS shim as they are configured to only talk a specific protocol instead of just TCP. They rely on receiving some sort of confirmation or direction instead of acting as dumb obfuscators. More specifically, this summer I've been working on generalizing a prototype that David Fifield(dcf1) and Ximin Luo(infinity0) built chaining together the pluggable transports obfs3 and flashproxy. The main features I've added to Fog include Generalizing Fog to use any pluggable transports instead of just obfs3 and flashproxy Generalizing Fog to use any number of pluggable transports to obfuscate data I modified how Tor connects to Fog, it now uses a SOCKS server to recieve the request from Tor instead of receiving TCP from the first pluggable transport as it did before. Added configuration systems to both Fog client and Fog Server to parse a format similar to the torrc config files. Added the ability to support multiple chains with one instance of Fog. The Fog client will only launch one copy of each pluggable transport even if that pluggable transport is used in multiple chains. Over the next few weeks outside of GSoC I plan on adding A system of passing ClientTransportOptions and ServerTransportOptions to the chain of pluggable transports. (I worked on this the last two weeks but was not able to submit it for code review before GSoC ended) Tests for everything! (Some are written but they are currently in code review, others will follow) Documentation. This email is just a general description of Fog, I'll be adding a bunch more documentation about the structure of fog and a guide to use it. Attempting to package Fog as a binary similar to Obfsproxy, though I've heard bad things about Py2Exe. In the future, Fog may need to Modify the PT-Spec to force all pluggable transport servers to transmit metadata about what IP/port the connection came from. This will let the Fog server use one copy of pluggable transport for multiple chains and fix an issue with high traffic causing data to be sent back in the wrong order. And thats about it for me. I'm headed back to UIUC next week but as when I have free time, I probably will continue contributed patches to Fog and maybe other parts of the Tor Project. I've had a great summer working for the Tor Project. Its been an awesome time developing Fog and I've learned a massive amount. I can't thank Infinity0 enough for being my main mentor and teaching me a ton about what's needed to do open source. He's really guided me to be a better coder and I'm thankful that he was able to put up with my at times messy/lazy code. I thought I knew something about how to write clean code at the beginning of summer. Now I know that I knew nothing lol. Seriously, Infinity0, thanks so much! I would also like to thank dcf for being my backup mentor and helping with questions about how the Fog server worked/potential enhancements to it. You can see the latest version of Fog at [1] Quinn [0] https://gitweb.torproject.org/torspec.git/blob/HEAD:/pt-spec.txt [1] https://github.com/infinity0/fog

1 0

[GSoC] HTTPS Everywhere's Secure Ruleset Updater - Final Report
by Red 19 Aug '14

19 Aug '14

Hello everyone! Today is the official "pencils down" date for Google Summer of Code, so I am going to outline the results of my work this Summer as a way of concluding my project. The first thing I had done at the start of my project was learn about Mozilla's XPCOM components and how they are used to interface with Gecko and other Firefox internals from extension code. I also learned about special files included with any extension such as install.rdf which are used to describe an extension's version information and signature-verifying public key, among other things. This lead me to understanding how extensions are updated and discover the kinds of limitations I would find in trying to update HTTPS Everywhere's rulesets library without changing the rest of the extension. The next thing I did was draft the specification for the format of the JSON manifest used to describe ruleset updates and explain how the process of updating the rulesets library would work. This work has since been built on and improved, and the existing specification document can be found in my fork of the extension, and is linked below[0]. This document describes everything one needs to know about the ruleset updater. It details: * How an object signing certificate can be generated using certutil from the NSS toolset. * How to create an update.json manifest file using the ruleset_update_manifest.py utility script I created.[1] * How to sign the update.json file using pk1sign and an object signing certificate. * How update information is fetched and how download failures are handled. * How the contents of update.json and the rulesets library database file are verified to be authentic. * What the significance of each field in update.json is. * Approximately how the ruleset updating mechanism functions in pseudocode. After the details of how updating would work were outlined in updateJSONSpec.md, I began implementing the ruleset updater module code for the extension. I also started working on a way to write tests for HTTPS Everywhere that I would initially use to test my code. I discovered that Firefox extensions could import XPCOM components exported by other extensions added to a user's browser, and so began work on a separate extension[2] that could be installed and used solely for testing HTTPS Everywhere. This work was soon improved upon by my mentor, Yan, who had the idea of creating a skeleton of an extension inside of HTTPS Everywhere's own codebase[3]. This extension used the more modern Addon SDK, which includes a unit testing suite, enabling HTTPS Everywhere developers to start writing proper unit tests that could be included in the HTTPS-Everywhere repository and run from the command line. While the unit testing environment I now had available was very effective, I had run into some surprising difficulty with Mozilla's nsIDataSignatureVerified XPCOM component, used to verify the signatures we were generating. By this point, Yan and I had agreed to try to compute the signature over the SHA256 hash of update.json's contents, so that this data could be more easily transcribed from a regular work computer to the airgapped machine EFF uses to house an offline signing key. It was at this point that we found that the key and signatures OpenSSL were generating were, somehow, incompatible with nsIDataSignatureVerifier, and Yan managed to get the verification unit test to pass by using certutil and pk1sign. The same problem of verifying signatures was encountered again when I got around to testing the actual ruleset updater code again, and had to generate new data, despite using certutil and pk1sign. Quite unfortunately, this problem drained almost four whole weeks of my time, as I had been looking into solutions involving porting a Firefox extension signing tool called Uhura (written in Perl), which meant also trying to understand what the tool was doing with ASN.1 specifications, among other things. Finally, I found that the nsIDataSignatureVerifier tool successfully verified the signature I had created for testing when it was not the hash of update.json's contents that were signed and supplied to the verifier, but the contents of the file themselves. The component is poorly documented and, after reaching out to developers in Mozilla's ecosystem, I found that it isn't very well understood in general. As such, even now I do not really understand why the verifier did not behave as expected in this scenario. Regardless, while it is somewhat less convenient here to sign update.json, the signature verification process works. Finally, I was able to move on to solve the problems of downloading and verifying the authenticity of the rulesets database file, and of reinitializing the extension's rulesets with those of the new database file. These problems were technically nuanced, but have been solved. The ruleset updater has been integrated into my fork of the extension's repository on github. My tests of its performance have passed, and I am pleased to say that it appears to be working. I have since submitted a pull request[4] to have my work reviewed and merged, and have even made changes requested by Yan, who has reviewed my work already. I'd like to conclude by giving my thanks to everyone in both of these mailing lists. I have received some invaluable support and advice that has had a profoundly positive impact on my experience. I learned a lot from everyone that lent a hand, and I feel the project has benefited greatly from each of the contributions I received to my efforts. My mentor, Yan, has also been a pleasure to work with. Our weekly meetings added very significant structure to my workflow, helped to keep me organized, and were also a great opportunity for me to pique her brain for ideas and possible solutions to some of the tougher problems I've encountered. I sincerely regard this as having been a positive experience, and I hope that everyone who has helped me until now is satisfied with my efforts and the actual results of my work. Thanks, everyone! [0] - https://github.com/redwire/https-everywhere/blob/master/doc/updateJSONSpec.… [1] - https://github.com/redwire/https-everywhere/blob/master/utils/ruleset_updat… [2] - https://github.com/redwire/https-everywhere-testing [3] - https://github.com/EFForg/https-everywhere/tree/master/https-everywhere-tes… [4] - https://github.com/EFForg/https-everywhere/pull/437

1 0

[PATCH 1/4] Remove some unused variables
by Daniel Martí 18 Aug '14

18 Aug '14

Signed-off-by: Daniel Martí <mvdan(a)mvdan.cc> --- lib/chutney/TorNet.py | 5 ++--- lib/chutney/Traffic.py | 1 - 2 files changed, 2 insertions(+), 4 deletions(-) diff --git a/lib/chutney/TorNet.py b/lib/chutney/TorNet.py index 3685ec0..9d8efd1 100644 --- a/lib/chutney/TorNet.py +++ b/lib/chutney/TorNet.py @@ -297,7 +297,6 @@ class LocalNodeBuilder(NodeBuilder): """ datadir = self._env['dir'] tor = self._env['tor'] - idfile = os.path.join(datadir,'keys',"identity_key") cmdline = [ tor, "--quiet", @@ -445,9 +444,9 @@ class LocalNodeController(NodeController): def hup(self): """Send a SIGHUP to this node, if it's running.""" pid = self.getPid() - running = self.isRunning() + running = self.isRunning(pid) nick = self._env['nick'] - if self.isRunning(): + if running: print "Sending sighup to %s"%nick os.kill(pid, signal.SIGHUP) return True diff --git a/lib/chutney/Traffic.py b/lib/chutney/Traffic.py index 7202c3d..57250f7 100644 --- a/lib/chutney/Traffic.py +++ b/lib/chutney/Traffic.py @@ -312,7 +312,6 @@ import sys def main(): """Test the TrafficTester by sending and receiving some data.""" DATA = "a foo is a bar" * 1000 - DATA_CORRUPT = "a foo is a baz" * 1000 proxy = ('localhost', 9008) bind_to = ('localhost', int(sys.argv[1])) -- Daniel Martí - mvdan(a)mvdan.cc - http://mvdan.cc/ PGP: A9DA 13CD F7A1 4ACD D3DE E530 F4CA FFDB 4348 041C

2 1

GSoC final progress update
by Белоус Михаил 18 Aug '14

18 Aug '14

During GSoC I have done following: Threadpool using pththread Benchmark for this pool Multithread version of command_proccess_cell and fix most of the data racing places Current version of tor daemon, passes chutney test, and chutney + valgrind for data racing test. I glad I work for tor, thank you all.

1 0

Proposal 220 (revised): Migrate server identity keys to Ed25519
by Nick Mathewson 18 Aug '14

18 Aug '14

I've revised proposal 220 based on commentary from Roger. The biggest changes is tweaking all of the things called "certificates" to make them actually follow the same format to greatest the extent possible. To see diffs, you can use git, or browse the gitweb site at https://gitweb.torproject.org/torspec.git/history/HEAD:/proposals/220-ecc-i… Filename: 220-ecc-id-keys.txt Title: Migrate server identity keys to Ed25519 Authors: Nick Mathewson Created: 12 August 2013 Target: 0.2.x.x Status: Draft [Note: This is a draft proposal; I've probably made some important mistakes, and there are parts that need more thinking. I'm publishing it now so that we can do the thinking together.] 0. Introduction In current Tor designs, router identity keys are limited to 1024-bit RSA keys. Clearly, that should change, because RSA doesn't represent a good performance-security tradeoff nowadays, and because 1024-bit RSA is just plain too short. We've already got an improved circuit extension handshake protocol that uses curve25519 in place of RSA1024, and we're using (where supported) P256 ECDHE in our TLS handshakes, but there are more uses of RSA1024 to replace, including: * Router identity keys * TLS link keys * Hidden service keys This proposal describes how we'll migrate away from using 1024-bit RSA in the first two, since they're tightly coupled. Hidden service crypto changes will be complex, and will merit their own proposal. In this proposal, we'll also (incidentally) be extirpating a number of SHA1 usages. 1. Overview When this proposal is implemented, every router will have an Ed25519 identity key in addition to its current RSA1024 public key. Ed25519 (specifically, Ed25519-SHA-512 as described and specified at http://ed25519.cr.yp.to/) is a desirable choice here: it's secure, fast, has small keys and small signatures, is bulletproof in several important ways, and supports fast batch verification. (It isn't quite as fast as RSA1024 when it comes to public key operations, since RSA gets to take advantage of small exponents when generating public keys.) (For reference: In Ed25519 public keys are 32 bytes long, private keys are 64 bytes long, and signatures are 64 bytes long.) To mirror the way that authority identity keys work, we'll fully support keeping Ed25519 identity keys offline; they'll be used to sign long-ish term signing keys, which in turn will do all of the heavy lifting. A signing key will get used to sign the things that RSA1024 identity keys currently sign. 1.1. 'Personalized' signatures Each of the keys introduced here is used to sign more than one kind of document. While these documents should be unambiguous, I'm going to forward-proof the signatures by specifying each signature to be generated, not on the document itself, but on the document prefixed with some distinguishing string. 2. Certificates and Router descriptors. 2.1. Certificates When generating a signing key, we also generate a certificate for it. Unlike the certificates for authorities' signing keys, these certificates need to be sent around frequently, in significant numbers. So we'll choose a compact representation. VERSION [1 Byte] CERT_TYPE [1 Byte] EXPIRATION_DATE [3 Bytes] CERT_KEY_TYPE [1 byte] CERTIFIED_KEY [32 Bytes] EXTENSIONS [variable length, up to length of certificate minus 64 bytes.] SIGNATURE [64 Bytes] The "VERSION" field holds the value [01]. The "CERT_TYPE" field holds a value depending on the type of certificate. (See appendix A.1.) The CERTIFIED_KEY field is an Ed25519 public key if CERT_KEY_TYPE is [01], or a SHA256 hash of some other key type depending on the value of CERT_KEY_TYPE. The EXPIRATION_DATE is a date, given in HOURS since the epoch, after which this certificate isn't valid. (A three-byte field here will work fine until 5797 A.D.) The EXTENSIONS field contains zero or more extensions, each of the format: ExtLength [1 or 2 bytes] ExtType [1 or 2 bytes] ExtData [Length bytes] The ExtLength and ExtType fields can represent values between 0 and 2^15-1, representing values under 128 as "0xxxxxxx" and values over 128 as "1xxxxxxx yyyyyyyy". The meaning of the ExtData field in an extension is type-dependent. It is an error for an extension to be truncated; such a certificate is invalid. Before processing any certificate, parties MUST know which identity key it is supposed to be signed by, and then check the signature. The signature is formed by signing the first N-64 bytes of the certificate prefixed with the string "Tor node signing key certificate v1". 2.2. Basic extensions 2.2.1. Signed-with-ed25519-key extension [type 04] In several places, it's desirable to bundle the key signing a certificate along with the certificate. We do so with this extension. ExtLength = 32 ExtData = An ed25519 key [32 bytes] When this extension is present, it MUST match the key used to sign the certificate. This 2.3. Revoking keys. We also specify a revocation document for revoking a signing key or an identity key. Its format is: FIXED_PREFIX [8 Bytes] VERSION [1 Byte] KEYTYPE [1 Byte] IDENTITY_KEY [32 Bytes] REVOKED_KEY [32 Bytes] PUBLISHED [8 Bytes] REV_EXTENSIONS [variable length, up to length of revocation document minus 64 bytes] SIGNATURE [64 Bytes] FIXED_PREFIX is "REVOKEID" or "REVOKESK". VERSION is [01]. KEYTYPE is [01] for revoking a signing key or [02] for revoking an identity key. REVOKED_KEY is the key being revoked; IDENTITY_KEY is the node's Ed25519 identity key. PUBLISHED is the time that the document was generated, in seconds since the epoch. REV_EXTENSIONS is left for a future version of this document. The SIGNATURE is generated with the same key as in IDENTITY_KEY, and covers the entire revocation, prefixed with "Tor key revocation v1". Using these revocation documents is left for a later specification. 2.4. Managing keys By default, we can keep the easy-to-setup key management properties that Tor has now, so that node operators aren't required to have offline public keys: * When a Tor node starts up with no Ed25519 identity keys, it generates a new identity keypair. * When a Tor node has an Ed25519 identity keypair, and it has no signing key, or its signing key is going to expire within the next 48 hours, it generates a new signing key to last 30 days. But we also support offline identity keys: * When a Tor node starts with an Ed25519 public identity key but no private identity key, it checks whether it has a currently valid certified signing keypair. If it does, it starts. Otherwise, it refuses to start. * If a Tor node's signing key is going to expire soon, it starts warning the user. If it is expired, then the node shuts down. 2.5. Router descriptors We specify the following element that may appear at most once in each router descriptor: "identity-ed25519" SP certificate NL The identity-key and certificate are base64-encoded with terminating =s removed. When this element is present, it MUST appear as the first or second element in the router descriptor. [XXX The rationale here is to allow extracting the identity key and signing key and checking the signature before fully parsing the rest of the document. -NM] The certificate has CERT_TYPE of [04]. It must include a signed-with-ed25519-key extension (see section 2.2.1), so that we can extract the identity key. When an identity-ed25519 element is present, there must also be a "router-signature-ed25519" element. It MUST be the next-to-last element in the descriptor, appearing immediately before the RSA signature. It MUST contain an ed25519 signature of the entire document, from the first character up to but not including the "router-signature-ed25519" element, prefixed with the string "Tor router descriptor signature v1". Its format is: "router-signature-ed25519" SP signature NL Where 'signature' is encoded in base64 with terminating =s removed. The signing key in the certificate MUST be the one used to sign the document. Note that these keys cross-certify as follows: the ed25519 identity key signs the ed25519 signing key in the certificate. The ed25519 signing key signs itself and the ed25519 identity key and the RSA identity key as part of signing the descriptor. And the RSA identity key also signs all three keys as part of signing the descriptor. 2.5.1. Checking descriptor signatures. Current versions of Tor will handle these new formats by ignoring the new fields, and not checking any ed25519 information. New versions of Tor will have a flag that tells them whether to check ed25519 information. When it is set, they must check: * All RSA information and signatures that Tor implementations currently check. * If the identity-ed25519 line is present, it must be well-formed, and the certificate must be well-formed and correctly signed, and there must be a valid router-signature-ed25519 signature. * If we require an ed25519 key for this node (see 3.1 below), the ed25519 key must be present. Authorities and directory caches will have this flag always-on. For clients, it will be controlled by a torrc option and consensus option, to be set to "always-on" in the future once enough clients support it. 2.5.2. Extra-info documents Extra-info documents now include "identity-ed25519" and "router-signature-ed25519" fields in the same positions in which they appear in router descriptors. Additionally, we add the base64-encoded, =-stripped SHA256 digest of a node's extra-info document field to the extra-info-digest line in the router descriptor. (All versions of Tor that recognize this line allow an extra field there.) 2.5.3. A note on signature verification Here and elsewhere, we're receiving a certificate and a document signed with the key certified by that certificate in the same step. This is a fine time to use the batch signature checking capability of Ed25519, so that we can check both signatures at once without (much) additional overhead over checking a single signature. 3. Consensus documents and authority operation 3.1. Handling router identity at the authority When receiving router descriptors, authorities must track mappings between RSA and Ed25519 keys. Rule 1: Once an authority has seen an Ed25519 identity key and an RSA identity key together on the same (valid) descriptor, it should no longer accept any descriptor signed by that RSA key with a different Ed25519 key, or that Ed25519 key with a different RSA key. Rule 2: Once an authority has seen an Ed25519 identity key and an RSA identity key on the same descriptor, it should no longer accept any descriptor signed by that RSA key unless it also has that Ed25519 key. These rules together should enforce the property that, even if an attacker manages to steal or factor a node's RSA identity key, the attacker can't impersonate that node to the authorities, even when that node is identified by its RSA key. Enforcement of Rule 1 should be advisory-only for a little while (a release or two) while node operators get experience having Ed25519 keys, in case there are any bugs that cause or force identity key replacement. Enforcement of Rule 2 should be advisory-only for little while, so that node operators can try 0.2.5 but downgrade to 0.2.4 without being de-listed from the consensus. [XXX I could specify a way to do a signed "I'm downgrading for a while!" statement, and kludge some code back into 0.2.4.x to better support that?] 3.2. Formats Vote and microdescriptor documents now contain an optional "id" field for each routerstatus section. Its format is: "id" SP "ed25519" SP ed25519-identity NL where ed25519-identity is base64-encoded, with trailing = characters omitted. In vote documents, it may be replaced by the format: "id" SP "ed25519" SP "none" NL which indicates that the node does not have an ed25519 identity. (In a microdescriptor, a lack of "id" line means that the node has no ed25519 identity.) [XXXX Should the id entries in consensuses go into microdescriptors instead? I think perhaps so. -NM] A vote or consensus document is ill-formed if it includes the same ed25519 identity key twice. 3.3. Generating votes An authority should pick which descriptor to choose for a node as before, and include the ed25519 identity key for the descriptor if it's present. As a transition, before Rule 1 and Rule 2 in 3.1 are fully enforced, authorities need a way to deal with the possibility that there might be two nodes with the same ed25519 key but different RSA keys. In that case, it votes for the one with the most recent publication date. (The existing rules already prevent an authority from voting for two servers with the same RSA identity key.) 3.4. Generating a consensus from votes This proposal requires a new consensus vote method. When we deploy it, we'll pick the next available vote method in sequence to use for this. When the new consensus method is in use, we must choose nodes first by ECC key, then by RSA key. First, for every {ECC identity key, RSA identity key} pair listed by over half of the voting authorities, list it, unless some other RSA identity key digest is listed more popularly for the ECC key. Break ties in favor of low RSA digests. Treat all routerstatus entries that mention this <ECC,RSA> pair as being for the same router, and all routerstatus entries that mention the same RSA key with an unspecified ECC key as being for the same router. Then, for every node that has previously not been listed, perform the current routerstatus algorithm: listing a node if it has been listed by at least N/2 voting authorities, and treating all routerstatuses containing the same identity as the same router. In other words: Let Entries = [] for each ECC ID listed by any voter: Find the RSA key associated with that ECC ID by the most voters, breaking ties in favor of low RSA keys. If that ECC ID and RSA key ID are listed by > N/2 voting authorities: Add the consensus of the routerstatus entries for those voters, along with the routerstatus entry for every voter that included that RSA key with no ECC key, to Entries. Include the ECC ID in the consensus. For each RSA key listed by any voter: If that RSA key is already in Entries, skip it. If the RSA key is listed by > N/2 voting authorities: Add the consensus of the routerstatus entries for those voters to Entries. Do not include an ECC key in the consensus. [XXX Think about this even more.] 4. The link protocol 4.1. Overview of the status quo This section won't make much sense unless you grok the v3 link protocol as described in tor-spec.txt, first proposed in proposal 195. So let's review. In the v3 link protocol, the client completes a TLS handshake with the server, in which the server uses an arbitrary certificate signed with an RSA key. The client then sends a VERSIONS cell. The server replies with a VERSIONS cell to negotiate version 3 or higher. The server also sends a CERTS cell and an AUTH_CHALLENGE cell and a NETINFO cell. The CERTS cell from the server contains a set of one or more certificates that authenticate the RSA key used in the TLS handshake. (Right now there's one self-signed RSA identity key certificate, and one certificate signing the RSA link key with the identity key. These certificates are X509.) Having received a CERTS cell, the client has enough information to authenticate the server. At this point, the client may send a NETINFO cell to finish the handshake. But if the client wants to authenticate as well, it can send a CERTS cell and an AUTENTICATE cell. The client's CERTS cell also contains certs of the same general kinds as the server's key file: a self-signed identity certificate, and an authentication certificate signed with the identity key. The AUTHENTICATE cell contains a signature of various fields, including the contents of the AUTH_CHALLENGE which the server sent cell, using the client's authentication key. These cells allow the client to authenticate to the server. 4.2. Link protocol changes for ECC ID keys We add four new CertType values for use in CERTS cells: 4: Ed25519 signing key 5: Link key certificate certified by Ed25519 signing key 6: Ed25519 TLS authentication key certified by Ed25519 signing key 7: RSA cross-certificate for Ed25519 identity key These correspond to types used in the CERT_TYPE field of the certificates. The content of certificate type [04] (Ed25519 signing key) is as in section 2.5 above, containing an identity key and the signing key, both signed by the identity key. Certificate type [05] (Link certificate signed with Ed25519 signing key) contains a SHA256 digest of the X.509 link certificate used on the TLS connection in its key field; it is signed with the signing key. Certificate type [06] (Ed25519 TLS authentication signed with Ed25519 signing key) has the signing key used to sign the AUTHENTICATE cell described later in this section. Certificate type [07] (Cross-certification of Ed25519 identity with RSA key) contains the following data: ED25519_KEY [32 bytes] EXPIRATION_DATE [4 bytes] SIGNATURE [128 bytes] Here, the Ed25519 identity key is signed with router's RSA identity key, to indicate that authenticating with a key certified by the Ed25519 key counts as certifying with RSA identity key. (The signature is computed on the SHA256 hash of the non-signature parts of the certificate, prefixed with the string "Tor TLS RSA/Ed25519 cross-certificate".) (There's no reason to have a corresponding Ed25519-signed-RSA-key certificate here, since we do not treat authenticating with an RSA key as proving ownership of the Ed25519 identity.) Relays with Ed25519 keys should always send these certificate types in addition to their other certificate types. Non-bridge relays with Ed25519 keys should generate TLS link keys of appropriate strength, so that the certificate chain from the Ed25519 key to the link key is strong enough. We add a new authentication type for AUTHENTICATE cells: "Ed25519-TLSSecret", with AuthType value 2. Its format is the same as "RSA-SHA256-TLSSecret", except that the CID and SID fields support more key types; some strings are different, and the signature is performed with Ed25519 using the authentication key from a type-6 cert. Clients can send this AUTHENTICATE type if the server lists it in its AUTH_CHALLENGE cell. Modified values and new fields below are marked with asterisks. TYPE: The characters "AUTH0002"* [8 octets] CID: A SHA256 hash of the initiator's RSA1024 identity key [32 octets] SID: A SHA256 hash of the responder's RSA1024 identity key [32 octets] *CID_ED: The initiator's Ed25519 identity key [32 octets] *SID_ED: The responder's Ed25519 identity key, or all-zero. [32 octets] SLOG: A SHA256 hash of all bytes sent from the responder to the initiator as part of the negotiation up to and including the AUTH_CHALLENGE cell; that is, the VERSIONS cell, the CERTS cell, the AUTH_CHALLENGE cell, and any padding cells. [32 octets] CLOG: A SHA256 hash of all bytes sent from the initiator to the responder as part of the negotiation so far; that is, the VERSIONS cell and the CERTS cell and any padding cells. [32 octets] SCERT: A SHA256 hash of the responder's TLS link certificate. [32 octets] TLSSECRETS: A SHA256 HMAC, using the TLS master secret as the secret key, of the following: - client_random, as sent in the TLS Client Hello - server_random, as sent in the TLS Server Hello - the NUL terminated ASCII string: "Tor V3 handshake TLS cross-certification with Ed25519"* [32 octets] RAND: A 24 byte value, randomly chosen by the initiator. [24 octets] *SIG: A signature of all previous fields using the initiator's Ed25519 authentication flags. [variable length] If you've got a consensus that lists an ECC key for a node, but the node doesn't give you an ECC key, then refuse this connection. 5. The extend protocol We add a new NSPEC node specifier for use in EXTEND2 cells, with LSTYPE value [03]. Its length must be 32 bytes; its content is the Ed25519 identity key of the target node. Clients should use this type only when: * They know an Ed25519 identity key for the destination node. * The source node supports EXTEND2 cells * A torrc option is set, _or_ a consensus value is set. We'll leave the consensus value off for a while until more clients support this, and then turn it on. When picking a channel for a circuit, if this NSPEC value is provided, then the RSA identity *and* the Ed25519 identity must match. If we have a channel with a given Ed25519 ID and RSA identity, and we have a request for that Ed25519 ID and a different RSA identity, we do not attempt to make another connection: we just fail and DESTROY the circuit. If we receive an EXTEND or EXTEND2 request for a node listed in the consensus, but that EXTEND/EXTEND2 request does not include an Ed25519 identity key, the node SHOULD treat the connection as failed if the Ed25519 identity key it receives does not match the one in the consensus. 6. Naming nodes in the interface Anywhere in the interface that takes an $identity should be able to take an ECC identity too. ECC identities are case-sensitive base64 encodings of Ed25519 identity keys. You can use $ to indicate them as well; we distinguish RSA identity digests by length. When we need to indicate an Ed25519 identity key in a hostname format (as in a .exit address), we use the lowercased version of the name, and perform a case-insensitive match. (This loses us a little less than one bit per byte of name, leaving plenty of bits to make sure we choose the right node.) Nodes must not list Ed25519 identities in their family lines; clients and authorities must not honor them there. (Doing so would make different clients change paths differently in a possibly manipulatable way.) Clients shouldn't accept .exit addresses with Ed25519 names on SOCKS or DNS ports by default, even when AllowDotExit is set. We can add another option for them later if there's a good reason to have this. We need an identity-to-node map for ECC identity and for RSA identity. The controller interface will need to accept and report Ed25519 identity keys as well as (or instead of) RSA identity keys. That's a separate proposal, though. 7. Hidden service changes out of scope Hidden services need to be able to identify nodes by ECC keys, just as they will need to include ntor keys as well as TAP keys. Not just yet though. This needs to be part of a bigger hidden service revamping strategy. 8. Proposed migration steps Once a few versions have shipped with Ed25519 key support, turn on "Rule 1" on the authorities. (Don't allow an Ed25519<->RSA pairing to change.) Once the release with these changes is in beta or rc, turn on the consensus option for everyone who receives descriptors with Ed25519 identity keys to check them. Once the release with these changes is in beta or rc, turn on the consensus option for clients to generate EXTEND2 requests with Ed25519 identity keys. Once the release with these changes has been stable for a month or two, turn on "Rule 2" on authorities. (Don't allow nodes that have advertised an Ed25519 key to stop.) 9. Future proposals * Ed25519 identity support on the controller interface * Supporting nodes without RSA keys * Remove support for nodes without Ed25519 keys * Ed25519 support for hidden services * Bridge identity support. * Ed25519-aware family support A.1. List of certificate types The values marked with asterisks are not types corresponding to the certificate format of section 2.1. Instead, they are reserved for RSA-signed certificates to avoid conflicts between the certificate type enumeration of the CERTS cell and the certificate type enumeration of in our Ed25519 certificates. **[00],[01],[02],[03] - Reserved to avoid conflict with types used in CERTS cells. [04] - signing a signing key with an identity key (Section 2.5) [05] - TLS link certificate signed with ed25519 signing key (Section 4.2) [06] - Ed25519 authentication key signed with ed25519 signing key (Section 4.2) **[07] - reserved for RSA identity cross-certification (Section 4.2) A.2. List of extension types [01] - signed-with-ed25519-key (section 2.2.1) A.3. List of signature prefixes We describe various documents as being signed with a prefix. Here are those prefixes: "Tor router descriptor signature v1" (section 2.5) "Tor node signing key certificate v1" (section 2.1) A.4. List of certified key types [01] ed25519 key [02] SHA256 hash of an RSA key [03] SHA256 hash of an X.509 certificate A.5. Reserved numbers We need a new consensus algorithm number to encompass checking ed25519 keys and putting them in microdescriptors. We need new CertType values for use in CERTS cells. We reserved in section 4.2. 4: Ed25519 signing key 5: Link key certificate certified by Ed25519 signing key 6: TLS authentication key certified by Ed25519 signing key 7: RSA cross-certificate for Ed25519 identity key

4 3

PKCS#1 ASN.1 Public Key Encoding
by Gareth Owen 17 Aug '14

17 Aug '14

Hi all I wonder if someone might be able to help me with the above. I understand, that to generate the digest, the PK must be encoded in PKCS#1 format. And further to this, the public keys in the router descriptors are NOT in PKCS#1 format, but plain ASN.1. I'm trying to generate the fingerprint given just the pubilc key in Java and after almost a whole day I'm about to give up. Does anyone have a sample PKCS#1 encoded public key that is used immediately before SHA-1 to generate the fingerprint? e.g. a hex string is what I'm after. It seems there are subtle ways that an PKCS#1 can vary while encoding the same information which affects the hash, Java seems to be doing it one way, OpenSSL another, an example on stack overflow adds an extra field, etc. Many thanks Gareth

2 2

Re: [tor-dev] Decentralized VOIP over Tor
by terryz＠Safe-mail.net 17 Aug '14

17 Aug '14

I looked at Ostel. Can Ostel be routed over Tor or is there another way to get anonymity using Ostel? I said decentralized VOIP because no central servers would be managing the communications. Any Tor node could possibly be a VOIP server. The network data would have to be continually distributed throughout Tor. Also I was thinking about an option for a user to generate and use their own AES keys via air gap or Diffie–Hellman. I'm interested in this because there's way too many good people hurt by the eavesdropping on telecommunication networks. Thanks, --TZ -------- Original Message -------- From: Jordan <jordannh(a)sent.com> To: tor-dev(a)lists.torproject.org Cc: terryz(a)safe-mail.net Subject: Re: [tor-dev] Decentralized VOIP over Tor Date: Fri, 15 Aug 2014 18:43:22 -0700

2 1

On picking Introduction Points in Next Generation Hidden Services
by George Kadianakis 17 Aug '14

17 Aug '14

One missing piece of rend-spec-ng.txt [0] is a section on how HSes should pick their Introduction Points (IPs). There are three main questions here: - How many IPs should an HS have? - Which relays can be IPs? - What's the lifetime of an IP? ==Introduction Points attacks== Before exploring these questions it's a good idea to state a rough threat model for IPs. First, let's get a visual taste, here is how IPs work in the current HS protocol: https://people.torproject.org/~asn/hs/ip_placement_currently.jpg (number of IPs reduced to 2 to make it more readable) As you can see, IPs are in a good position to conduct any of the following attacks: a) IPs can count the number of introductions for a subset of clients (i.e. in the figure above, IP_1 would be able to count introductions from the clients above it). Since clients pick IPs uniformly at random, it's not hard to extrapolate from that to the total number of introductions. b) IPs have presense information about the HS. That is, they know whether the HS is up or down at a given time since they have a long-term stable circuit to it. FWIW, regular clients also have this ability by continuously "pinging" the HS and noticing when it's down. And, of course, an attacker who controls all the IPs of an HS can trivially DoS the HS (till the HS refreshes its IPs). Furthermore, as part of the Next Generation HSes initiative [0], we are considering enhancing the availability of HSes by allowing multiple nodes per Hidden Service. A plausible idea for achieving that is to allow multiple IP circuits per Introduction Point, as explained in [tor-dev] by Christopher Baines [1]. This means that IPs would work like this: https://people.torproject.org/~asn/hs/ip_placement_scaling.jpg where HS_1, HS_2 and HS_3 are the various nodes of the HS. This allows the IPs to launch the following attacks: a) IPs can learn the number of nodes of an HS, by counting the number of IP circuits on them. Also, the IPs can learn the prsense of the nodes of an HS, by looking at the state of their circuit. b) IPs can choose which HS node will receive traffic. ==How many IPs should an HS have?== Now let's investigate how many IPs an HS should have. The current situation is that HSes attempt to estimate their own popularity [2], and then they launch a number of IPs between 3 and 10 depending on how popular they think they are. FWIW, we don't really understand whether the formula works properly [3]. There are a few options for the future here: a) Fix the formula and keep number of IPs dynamic based on the popularity of the HS. This is not a bad idea. However, we should make sure that from the number of IPs you can't easily derive the number of clients of the HS. Also we should make sure that the formula works properly. b) Have a static amount of IPs per HS. For example '5' of them. I'm not sure what kind of calculations we need to do to find the right constant here (same for the (a) option). c) Have a static amount of IPs per HS, but also allow this to be configurable by the HS operator. The idea here is that popular HSes can pump up the number of IPs to make the service more reachable. It's worth noting that HSes who do so will stand out as manually configured; not sure if any other partition attacks can happen here. Also, there is also the danger of all HS operators thinking they are special and pumping the number of IPs to 42. Generally, we want to have a healthy amount of IPs (so that they don't get DoSed, and that requests get load balanced nicely), but also not too many because every HS having many IP circuits will put a load to the network (especially with services like Torchat where each client is an HS), and also because we want to avoid too many nodes becoming our IPs over time (more on this below). ==Which relays can be IPs?== This seems to be the easiest question here and Tor is currently handling it well by only restricting IPs to be Stable nodes [4]. This means that with the current network, we have about 4000 possible IPs to choose from [5]. This makes sense since we want to maximize the set of possible IPs, but we also want them to be stable to decrease their natural churn. ==What's the lifetime of an IP?== Another hard question: How long should we keep IPs for? Currently, Tor keeps IPs for a random time between 18 to 24 hours [6]. This seems like too short of a period if we actually want to protect against adversarial nodes ever becoming our IPs: Consider an HS with 5 IPs that rotates them every 24 hours, in only two months it will use 300 nodes as IPs plus the natural churn (which is not negligible at all). With that in mind we need to look at all the possible attacks that IPs could launch and decide whether they should be short-lived or long-lived. For example, waldo in a related thread [7] [8] asks for short-lived IPs, but recent entry guard research has shown that making guards more long-lived is actually beneficial for security [9]. I'm personally leaning towards more long-lived IPs but I still don't know what our constants should be. I could see anything from a week, to a month, to 5 months as reasonable IP lifetimes. We also need to look at INTRO_POINT_LIFETIME_INTRODUCTIONS, since apparently in the current code, IPs will expire on their own if they perform more than 16384 introductions. ==Conclusion== I hope that this thread serves as a good start on discussing Introduction Point security. After we take some decisions, we will need to write them down as a proposal and incorporate them in rend-spec-ng.txt. Also, this thread does not explore other IP matters, like how many HS nodes should correspond to each IP if we go ahead with the scaling ideas [10]. I decided to not include this in the discussion, so that we keep it simple and also so that we don't focus on a particular scaling scheme. References: [0]: https://gitweb.torproject.org/torspec.git/blob/HEAD:/proposals/224-rend-spe… [1]: https://lists.torproject.org/pipermail/tor-dev/2014-April/006788.html [2]: https://gitweb.torproject.org/tor.git/blob/ab3d5c049032651a9c9164262f9a8f81… [3]: https://trac.torproject.org/projects/tor/ticket/8950 [4]: https://gitweb.torproject.org/tor.git/blob/bb68c731b897a967a4b7eb138728fa07… [5]: https://metrics.torproject.org/network.html#relayflags [6]: https://gitweb.torproject.org/tor.git/blob/bb68c731b897a967a4b7eb138728fa07… https://gitweb.torproject.org/tor.git/blob/bb68c731b897a967a4b7eb138728fa07… [7]: https://lists.torproject.org/pipermail/tor-dev/2014-May/006815.html [8]: waldo also mentions an IP guard discovery attack in another reply of his: https://lists.torproject.org/pipermail/tor-dev/2014-May/006843.html However, I'm not sure if it's actually doable, since I think that HSes will discard an IP that has failed a circuit. We need to look into this more seriously. [9]: https://blog.torproject.org/blog/improving-tors-anonymity-changing-guard-pa… [10]:https://lists.torproject.org/pipermail/tor-dev/2013-October/005615.html https://lists.torproject.org/pipermail/tor-dev/2013-October/005683.html

3 3

Orbot & Orfox - GSoC bi-weekly report 6
by Amogh Pradeep 17 Aug '14

17 Aug '14

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Status Report 6 August 17th, 2014. So the past couple of weeks have been a little more hectic than usual, but these are the things that I got to work on: 1) Continuing work on fixing leak: On the Mozilla side, I had a long discussion with snorp and rnewman, they seem to have an idea to solve proxying everything through the added proxy settings but this is going to be one massive bug, so I haven't been able to land it yet. Bugs are http://bugzil.la/942652, http://bugzil.la/942653 and http://bugzil.la/942654. Fixing the first two should solve the dns leak. 2) Temporary loadFavicon fix: As you will be able to see my changes at https://github.com/amoghbl1/gecko-dev/commit/4baa2111b7d8a90af5b7bb787cc9d5… , I have a temporary fix for this, but hopefully this won't be necessary after the above mentioned bugs are fixed. 3) Getting Orfox built on the guardian projects build server: Hopefully this will be done before Monday, although all the code for the app is there, if we could provide the apk officially before hard pencils down, it would be nicer. This has been one great summer for me, I've had loads of fun, learned a lot and met some amazing people. I thank everyone for their support and look forward to continuing working with you guys. -----BEGIN PGP SIGNATURE----- iQEcBAEBAgAGBQJT8KzvAAoJELm/SSKdtjUkrS8IAIrgJYhvdoa6+7HGfHPqu0cq ocQX8Hd67hXwHrtGHmmdS3c7aCOyV4K0g/aGi4WTVbFRqd+tFzHNK9zTKYpUvXXP wfuORN/SKWCnjLrmjQ6ZXks1+mq7lnaTxSAPYo4GCJj6nTbDzDZryHlHncxMQheA VoU+0JV9bg7OAYpLDaF/4/TPSqG1KE5H5Ae633dXBt0/dmMhFmhNtfJdbNrlilIz UleRhERZe5h94Bz6QYJtCeD0zOdnHxI0udT73c7MYCLTiS7SxFssZYuUiE1grpHl GgVvnR8vfwFCgz7O6WLven+bfOMGZV0ZJZCIPopyZ7HXw034WmTgKLbLQl2H1cM= =ymdp -----END PGP SIGNATURE-----

2 1

GSoC final progress update (Stegotorus)
by Noah Rahman 17 Aug '14

17 Aug '14

The following tickets were largely achieved (last is in process of debugging) - adding config file (see branch https://github.com/TheTorProject/stegotorus/tree/f--modus-operandi) - adding elligator handshake ( https://github.com/TheTorProject/stegotorus/tree/f--circuit-handshake) [0] - moving remaining stegs over to class-based structure (see note (1) below) (https://github.com/TheTorProject/stegotorus/tree/f--file-stegize-swf-js-pdf ) The following are "on deck" and I intend to work on them after GSoC code submission date of August 22. - SOCKS proxy over wire from Tor (see https://github.com/SRI-CSL/stegotorus/commit/2d4ac59b8112611a7b63a1c5b15dfb… and https://github.com/SRI-CSL/stegotorus/commit/c799f30249c5e1dfbcc1adfe68f6bd… ) - adding SRI code into Tor fork (such as new JSON steg) - this was simply not anywhere near ready in time for the summer, but now has TBB and gitian ready to go - making transparent proxy robust (as security measure in case stegotorus server is probed) [0] this needs one last check for out of order packets. [1] I was hypothesizing that new larger default buffer size or excessive pointer casting was causing performance issues, but perusal of JavaScript patch via valgrind revealed memory leaks in the decompression methods of several steg mod classes. I am in the process of addressing this. This causes intermittent, not consistent failures, so unit tests would not consistently catch this.

1 0

Re: [tor-dev] Decentralized VOIP (or video chat) over Tor
by terryz＠Safe-mail.net 16 Aug '14

16 Aug '14

FreeNote's overview is almost the same as what I'm thinking. I've used GTK and GStreamer for Video in the past and implemented mobile and desktop IPTV applications using Qt, SDL, Ogg, Theora, and Vorbis. This VOIP over Tor idea came to mind after developing a prototype VOIP application using Qt with custom protocols and encryption. The users generated their own AES keys and added them to the VOIP client through the user-interface. The VOIP server didn't do any encryption/decryption only the client and only public-key information was allowed to be transmitted to peers, but the packets did go through central servers. It wasn't decentralized and no anonymity was in the design. It would be nice to have this work over Tor. I would like to focus on this task if possible. --TZ -------- Original Message -------- From: Griffin Boyce <griffin(a)cryptolab.net> Apparently from: tor-dev-bounces(a)lists.torproject.org To: tor-dev(a)lists.torproject.org Subject: Re: [tor-dev] Decentralized VOIP (or video chat) over Tor Date: Fri, 15 Aug 2014 22:14:09 -0400 > > This is similar, though not *quite* the same. A while back ioerror > released FreeNote[1], which makes it easier to broadcast audio and video > on a hidden service. This is a pretty cool idea and works pretty well. > AND it should be pointed out that two one-way conversations can be a > two-way conversation by virtue of just sharing the links over OTR [2]. > > Scott Ainslie and I discussed the possibility of taking that basic > two-way conversation hidden service concept and making a GUI for it with > Glade+GTK. Unfortunately, neither of us really have the time or > expertise for this endeavor. I got as far as wireframing some ideas > before going face-first into developing a more time-sensitive project > [3]. I'd love it if someone actually did this and released their > prototype as free software. There are way too many issues with > centralized services like Skype and Google Hangouts.[4] > > best, > Griffin > > > [1] https://github.com/ioerror/freenote > [2] Of course, if someone shares the links further, there can be privacy > issues. > [3] Satori: https://github.com/glamrock/Satori > [4] and jitsi never recognizes my fucking microphones =/ > > On 2014-08-15 21:43, Jordan wrote: > > Hi, terryz, > > > > Thanks for the idea! Today I was actually wondering if *video* were > > possible, > > too. :-D > > > > Guardian project has [Ostel](https://guardianproject.info/apps/ostel/). > > Is > > that what you're wanting? If not, was there a feature you were wanting > > from > > Ostel or another application that has features that Ostel doesn't? > > > > As for "decentralized," I think the whole point of tor is that tor > > itself is > > decentralized. Check out [Running a relay] > > (https://www.torproject.org/docs/tor-doc-relay.html.en) to see how this > > works. > > > > Again, thanks for the input! :-D > > > > On Friday, August 15, 2014 05:53:44 PM terryz(a)Safe-mail.net wrote: > >> Hi, > >> > >> I'm interested an anonymous decentralized VOIP network on Tor. All > >> traffic > >> routed through Tor. Every Tor user being an optional server for PTT or > >> Continuous Speech. > >> > >> How feasible does this sound? > >> > >> > >> --TZ > >> _______________________________________________ > >> tor-dev mailing list > >> tor-dev(a)lists.torproject.org > >> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev > > > > _______________________________________________ > > tor-dev mailing list > > tor-dev(a)lists.torproject.org > > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev > _______________________________________________ > tor-dev mailing list > tor-dev(a)lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

1 0