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

Running doctor's sybil checker over archived consensuses
by Philipp Winter 20 Jan '15

20 Jan '15

I reimplemented doctor's sybil checker [0] in Go [1] which makes it possible to (somewhat) quickly analyse archived consensuses. The algorithm is quite simple. It iterates over every consensus ever published, keeps track of all relay fingerprints, and tells us how many previously unseen relay fingerprints are present in every consensus. I put the results, time series ranging from 2007 to 2014, online [2]. One can see a bunch of suspicious spikes in some of the years. I manually checked the events and summed them up below. But first, here are some basic statistics about the amount of new fingerprints: Min. : 0.000 1st Qu.: 4.000 Median : 6.000 Mean : 6.377 3rd Qu.: 8.000 Max. :3020.000 The median amount of new fingerprints in a consensus is six. The maximum number observed is 3,020 which was caused by the sybil attack last December. Here are some preliminary notes about the most significant spikes. I'll have a more detailed analysis at some point in the future. 2007-11-12: Missing consensuses. 2008-07-22: Missing consensuses. 2008-09-19: Some missing consensuses and a small group called "torism" came online. 2008-10-25: Missing consensuses. 2010-06-26: Several hundred PlanetLab relays came online. At least their nickname contained "planetlab" or some variation thereof. 2010-09-23: The trotsky relays which were suspected to be part of a botnet. 2010-10-02: Again trotsky relays. 2012-11-15: Several hundred clearly related relays, at least some of which in Amazon's EC2 IP address space, come online. 2013-02-04: A group very similar to the previous one comes online. 2014-01-30: A clearly related group of relays comes online, presumably the one from the pulled Blackhat talk. 2014-11-17: Several probably related relays in the Google cloud get online. 2014-12-26: Many relays named LizardNSA and FuslVZTOR come online. 2014-12-30: Many relays named anonpoke come online. [0] <https://gitweb.torproject.org/doctor.git/tree/sybil_checker.py> [1] <https://gitweb.torproject.org/user/phw/sybilhunter.git/> [2] <http://www.nymity.ch/new_fingerprints/> Cheers, Philipp

3 5

Consensus weight dropped
by Bram de Boer 19 Jan '15

19 Jan '15

All, In December consensus weight of many nodes suddenly dropped. Using the onionoo database I have calculated the average consensus weight during 18-25 october 2014, and the average consensus weight during 11-18 january 2015 of all relays that exist longer than half a year and sorted them by the amount the consensus weight has dropped: http://nosur.com/consensus.txt Almost all of the relays at the top of the list show the same drop in December and the short spike around januari 6th. The exits I operate used to contribute around 80 Mbps to the network but are now down to no more than 0.05 Mbps. I am aware of the Lizard Squad annoyance around that time, but the disruption seems to continue for many old relays. Has there been a change in the consensus calculation that might be causing this? Thanks, Bram de Boer

1 0

Revisiting exit node notification page
by CJ 18 Jan '15

18 Jan '15

Heya! While I re-built my server and my exit node, I took some time in order to get a fancier notification page for the exit node: https://tor.tengu.ch/ It might be good/interesting to provide something a bit better than the default HTML in the package (at least debian package). The current page I got is based on bootstrap and, thus, might have some license issue if this has to be included in a package, but I'm pretty sure we might get something independent. Would you, the dev team, be interested in such a new look for this page? If so, I might take some time in order to provide html/css stuff without any dependence on some other stuff (though, on my page, all is included locally). Cheers, C.

2 2

Is it time to drop support for the v1/v2 protos?
by Tom van der Woerdt 15 Jan '15

15 Jan '15

Hi all, After reading the Tor spec [1] I did some digging and realized that the old handshakes and link protocols (v1 (certs up-front) and v2 (renegotiation)) are not used anymore as of 0.2.3.6-alpha which introduced link proto v3. Supporting v1 and v2 requires (among other things) supporting SSLv3 which (imho) should be deprecated everywhere. This makes me wonder why Tor still supports these: is it for compatibility with even older versions (consensus health says no) or are there other reasons? If someone were to invest a couple of hours and remove all support for them from the Tor code and the Tor spec, would this hurt the network or would it be a welcome patch? Tom [1] https://gitweb.torproject.org/torspec.git/tree/tor-spec.txt

6 15

Re: [tor-dev] how to simulate TOR network through chutney?
by teor 15 Jan '15

15 Jan '15

On 15 Jan 2015, at 01:02 , tor-dev-request(a)lists.torproject.org wrote: > Date: Wed, 14 Jan 2015 13:28:22 +0100 > From: Mohiuddin Ebna Kawsar <mohiuddin.kawsar(a)gmail.com> > Subject: Re: [tor-dev] how to simulate TOR network through chutney? > > Hi, > > isn't it possible to set exit node by explicitly specifying > *ExcludeExitNodes test001a,test002a,test003r *in client torc file ? It's possible, but error-prone. Why not just configure only one exit node in the entire network, and then every node will have to use it? teor teor teor2345 at gmail dot com pgp 0xABFED1AC https://gist.github.com/teor2345/d033b8ce0a99adbc89c5 teor at blah dot im OTR C3C57B23 349825DE 929A1DEF C3531C25 A32287ED

2 1

Re: [tor-dev] how to simulate TOR network through chutney?
by teor 14 Jan '15

14 Jan '15

>> Date: Sun, 11 Jan 2015 14:09:56 +0100 >> From: Mohiuddin Ebna Kawsar <mohiuddin.kawsar(a)gmail.com> >> >> Hi teor, >> >> Thanks for quick reply. i just download new chutney from github and able to >> run chutney for nodes = a(3) + r(1) + c(1) but when i set nodes = a(3) + >> c(1) i got following message >> ############################################################## >> ./chutney start networks/basic-min >> Starting nodes >> <type 'exceptions.IOError'> >> Python 2.7.8: /usr/bin/python2 >> Sun Jan 11 14:00:27 2015 >> > > <snip> > >> >> /home/raboon/chutney-master/lib/chutney/TorNet.py in >> waitOnLaunch(self=<__main__.LocalNodeController object>) >> 636 # RunAsDaemon default is 0 >> 637 runAsDaemon = False >> 638 with open(self._getTorrcFname(), 'r') as f: >> 639 for line in f.readlines(): >> 640 stline = line.strip() >> builtinopen = <built-in function open> >> self = <__main__.LocalNodeController object> >> self._getTorrcFname = <bound method LocalNodeController._getTorrcFname of >> <__main__.LocalNodeController object>> >> f undefined >> <type 'exceptions.IOError'>: [Errno 2] No such file or directory: >> '/home/raboon/chutney-master/net/nodes/003c/torrc' > > <snip> > > Hi kawsar, > > chutney is complaining that you have 4 nodes in your new network, not 5 as it was expecting. > > Every time you change the torrc_templates or network files, you must run: > chutney configure > and perhaps some other commands. The authority logs show that an authority process is still running. Use: chutney stop Or the tor/src/test/test-network.sh command below will do it for you. > > You may find it easiest to use: > tor/src/test/test-network.sh > or > chutney/tools/bootstrap-network.sh > to do this for you. > > In particular, > tor/src/test/test-network.sh > will bootstrap and verify the entire network for you, and let you choose: > a network --flavour (e.g. basic-min) > a --delay before verifying the network (default 18 seconds in 0.2.6.2-alpha) > It will also let you configure chutney and tor paths, or you can: > set the CHUTNEY_PATH environmental variable to the chutney directory > use the default tor/src/or/tor in the build directory, or set the TOR_DIR environmental variable. teor teor2345 at gmail dot com pgp 0xABFED1AC https://gist.github.com/teor2345/d033b8ce0a99adbc89c5 teor at blah dot im OTR C3C57B23 349825DE 929A1DEF C3531C25 A32287ED

2 1

Pluggable transports meeting tomorrow (16:00 UTC Wednesday 14th of January 2015)
by David Fifield 13 Jan '15

13 Jan '15

Just wanted to remind you that the regular biweekly pluggable transports meeting is going to occur tomorrow at 16:00 UTC. Place is the #tor-dev IRC channel in the OFTC network. https://trac.torproject.org/projects/tor/wiki/doc/PluggableTransports#Plugg… David Fifield

1 0

Reminder for ooni weekly meeting today at 19:00 CET
by Arturo Filastò 13 Jan '15

13 Jan '15

This is to remind you that today Tuesday 13th of January at 19:00 CET (18:00 UTC) there will be the weekly ooni dev meeting. The channel is #ooni, the network is irc.oftc.net. See you there. ~ Arturo

1 0

Request to reschedule ooni dev meeting to Tuesday 13th
by Arturo Filastò 12 Jan '15

12 Jan '15

Hi, I have to study for an exam on Tuesday so it would be ideal for me if we could move the next ooni dev meeting to Tuesday. Does that work for those interested in attending? I would suggest we do it at the same time (19:00 CET). ~ Arturo

1 1

proposal 240: Early signing key revocation for directory authorities.
by Nick Mathewson 11 Jan '15

11 Jan '15

Filename: 240-auth-cert-revocation.txt Title: Early signing key revocation for directory authorities. Author: Nick Mathewson Created: 09-Jan-2015 Status: Draft 1. Overview This proposal describes a simple way for directory authorities to perform signing key revocation. 2. Specification We add the following lines to the authority signing certificate format: revoked-signing-key SP algname SP FINGERPRINT NL This line may appear zero or more times. It indicates that a particular not-yet-expired signing key should not be used. 3. Client and cache operation No client or cache should retain, use, or serve any certificate whose signing key is described in a revoked-signing-key line in a certificate with the same authority identity key. (If the signing key fingerprint appears in a cert with a different identity key, it has no effect: you aren't allowed to revoke other people's keys.) No Tor instance should download a certificate whose signing key,identity key combination is known to be revoked. 4. Authority operator interface. The 'tor-gencert' command will take a number of older certificates to revoke as optional command-line arguments. It will include their keys in revoked-signing-key lines only if they are still valid, or have been expired for no more than a month. 5. Circular revocation My first attempt at writing a proposal here included a lengthy section about how to handle cases where certificate A revokes the key of certificate B, and certificate B revokes the key of certificate A. Instead, I am inclined to say that this is a MUST NOT.

4 5