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

onionoo details document deterministic output
by nusenu 28 Apr '15

28 Apr '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi, if I ask two onionoo instances running the same version (as given in the header of the document) for the same details document, to what extend should they match if relays_published matches, sorting is been taken care of and lets assume that both instances use the same maxmind files and their DNS servers provide the same answers? One example: Torprojects instance says: "flags":[] cthulhu's instance says: "flags":[""] thanks, nusenu -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJVN+saAAoJEFv7XvVCELh0ywEP/RNsdjuOywrJMAuaSlLLwCYs eHK0EUcmq/DDyq2OaAK9wOgAYqtusgBp5+YhiL11dBAvuW2siTZJPiKcoj8UQk84 m6xq9FCImlxLIEe52YP+wz2t8y6p42oAiSqlMLgtBVjW6QvgK3ov0e++iEhbJbvj hKLeSPsVLHz5XWtUdSjQ5fbbpsuItzTphOc9bi/nWGGYzeRzBNdtXilU5afCysi5 GvxV2SdttRrZw0IVzbLs0CjZBBwxhiuR8yemjRTaL7QDBgS2x0TMCxqhDmVXbp70 eqwGf5Rvf9AYgGu6i+3CJk9YAPh4vcLx1XS8hKxwreIXsUpWGGOfZs3VCGVFcZKe T9oQKQgy/EX0DSi5CSU5mbAUB0XT6S6gzh2Q7ZrsYfMWOaZXuawfeyBcvp3l/gSQ vkZ496ilDsc0DK+z0rrGLNbabx3CoQmHBr8kJQS9ZqAzZEMuDETXKwOBD+IVvSYh wo7nCU9o0NrzuwQCLdjGWr7WoInMLnASgySit8sGsbjzGTigwMvbg6LD4VlUQmcj NFaofSw/KcTUDf2+ZFP5TdXOizaPHeYxfyXn+B8ntqktYav86ePpaCUtq50HMEl9 6BTKvVFcCHkpUbgYTTDFW6YMM1qSvwmODiyKQbkWaB3sItdiPZaHy5ejPSEfDRCz FOY1pHCNGjCJWjrmY5o6 =YbXp -----END PGP SIGNATURE-----

2 10

onionoo: increasing first_seen granularity + providing document fingerprints
by nusenu 28 Apr '15

28 Apr '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi, timestamps are useful to link relays, unfortunately onionoo only says in which consensus the relay was first seen (granularity: 1hour) but does not include the timestamp of the first seen descriptor that ended up in the consensus (published line). That timestamp would have a higher granularity (seconds). What do you think about adding such a timestamp? (I acknowledge that I might be the only user of this field) I might want to prove to third parties that I'm indeed processing/providing authentic historic onionoo documents from onionoo.tpo. What do you think of signing them? thanks -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJVOpLqAAoJEFv7XvVCELh0WaIP/jqLtHaeno0EEUNPeqT8rJQp XRV76Vfq6LOciexFBRfcN2p7kkG26Y1LunRs12QuRpJngNfSW/nu3/WNUruR205D PrFJCI2Olxn3s8Fktd/N5kNLJbtPDmzqkghhvWUP+f1MBuW0FstMWi4fZ+TyerE9 FTD8eTF8woFb/JEHIrKsH4LB5Os/uGCoJbWT+AlxKHQcU/mQn0rb4ZIIllbUr9LJ uuFUV7ajZAR/rBX2AWvpkJgaS3BfOk3cMOVd3dQgweDjtUlS66Q5v+vtvBHXYk1V jd+fXyQ3txFmFVj/oQgnJJFRmGSmqpm5hRWEkzOXjXlCdsnqMPUBBjwjrgU+vmGB sNQOi/NdXUImQ0bT+ryjPTOT7Gf5EXOihYyH4e4ebn5OEEEVTQh/86iXxrLB23I2 z7sciEw3q/Tt7mM21cSMRStxavBU5InixIvQz78TgK1sE9PpeohzhToxNedm8aDE Ny/O+KYBBBmKOuRwjmbyJQ86MxQHnmEwLhksVNSJ3MUuG0QmfFTrht3thkmlew6z UfFBS9YzfBIoztL7X5Pu4nFsNFy2ffxZIV/bs4Dmx1PlweIw0eUeCgUdcdZTcvA+ v4OjCukdzLupDpb8lhDuX5EqrmeYUnczlopMX3szeX8udLKr5G+MWaihGdKasdKw Fy6T4z11bbzuW/nBf6Ra =oJ6y -----END PGP SIGNATURE-----

2 1

ANN: OnionPy 0.3.0
by Lukas Erlacher 28 Apr '15

28 Apr '15

Hello all, I've updated OnionPy to respect the new "version" field in query responses. There are one or two new objects OnionPy doesn't parse fully, which I hope I can get to soon. Signed builds are on PyPI. [1] OnionPy is a pure-python OnionOO request wrapper that supports transparent caching. If you are planning to make something in python that uses the tor network status, accessing OnionOO [2] using OnionPy might be exactly what you need. If you are interested, check out the repo and readme! [3] Of course, criticism, suggestions, and pull requests are always welcome. Best regards, Luke PS: Yes, I know, the last update to the OnionOO protocol happened in December, so "new" is relative ;-) [1] https://pypi.python.org/pypi/OnionPy [2] https://onionoo.torproject.org/ [3] https://github.com/duk3luk3/onion-py

1 0

tor's "make test" fails when run on tails
by warms0x 27 Apr '15

27 Apr '15

I am trying to execute tor's tests from git (63a90f2) on tails but the socketpair_ersatz test keeps failing util/socketpair: [forking] OK util/socketpair_ersatz: [forking] FAIL src/test/test_util.c:4212: assert(0 OP_EQ tor_socketpair_fn(family, SOCK_STREAM, 0, fds)): 0 vs -111 [socketpair_ersatz FAILED] util/max_mem: OK The failure seems to be in connect(): https://gitweb.torproject.org/tor.git/tree/src/common/compat.c#n1492 armadev said on IRC that he/she could make the tests pass, so I wonder if there might be some specific behavior on tails that prevents the test from passing successfully. Is there a suggested workaround? Or perhaps is it possible to easily ignore this one test?

3 2

Bridge Clients à la Vidalia
by Kenneth Freeman 25 Apr '15

25 Apr '15

This may be a naïve question, but how do I parse the clients who have used my bridge relay on my Debian box à la Vidalia? Just set the syslog to info and run a search or script? I routinely tell my friends which nation-states have become especially active (an interesting metric of geopolitical turbulence in and of itself). Thanks!

2 1

HTTPS Everywhere harmful
by Maciej Soltysiak 25 Apr '15

25 Apr '15

http://www.w3.org/DesignIssues/Security-NotTheS.html Maciej

4 3

Impending Facebook Onion-Site Certificate Changes
by Alec Muffett 24 Apr '15

24 Apr '15

Hello All! Details: https://www.facebook.com/facebookcorewwwi/posts/703469239759799 <https://www.facebook.com/facebookcorewwwi/posts/703469239759799> Summary: new EV-style SSL certificate rolls out to facebookcorewwwi.onion next week. - alec — Alec Muffett Security Infrastructure Facebook Engineering London

1 0

Re: [tor-dev] Experimenting with private tor setup
by teor 23 Apr '15

23 Apr '15

> Date: Wed, 22 Apr 2015 01:05:44 -0400 > From: CJ Ess <zxcvbn4038(a)gmail.com> > > On Tue, Apr 21, 2015 at 9:01 AM, teor <teor2345(a)gmail.com> wrote: > > > > Date: Tue, 21 Apr 2015 02:13:48 -0400 > > > From: CJ Ess <zxcvbn4038(a)gmail.com> > > > > > > I've been experimenting with a private tor setup - I've managed to setup a > > > couple directory authorities, six routers/exit nodes (which seemed to be > > > the minimum to bootstrap everything), and a client. … > > > So I'm wondering what would happen if I set TestingTorNetwork to 0, so I > > > picked one onion router instance and made that change. > > > > > > Because its all running on one box I had to keep some of the special > > > settings: > > > DirAllowPrivateAddresses 1 > > > EnforceDistinctSubnets 0 > > > AuthDirMaxServersPerAddr 0 > > > AuthDirMaxServersPerAuthAddr 0 > > > ExtendAllowPrivateAddresses 1 > > > > > > And that almost works, I got this far: > > > > > > Apr 21 00:50:09.000 [notice] Bootstrapped 100%: Done > > > Apr 21 00:50:09.000 [notice] Now checking whether ORPort > > > xxx.18.110.101:5106 is reachable… (this may take up to 20 minutes -- look > > > for log messages indicating success) > > > Apr 21 01:10:09.000 [warn] Your server (xxx.18.110.101:5106) has not > > > managed to confirm that its ORPort is reachable. Please check your > > > firewalls, ports, address, /etc/hosts file, etc. > > > Apr 21 01:30:09.000 [warn] Your server (xxx.18.110.101:5106) has not > > > managed to confirm that its ORPort is reachable. Please check your > > > firewalls, ports, address, /etc/hosts file, etc. > > > > > > It looks like the "is reachable" is determined by opening a circuit. … > > > I don't see any warnings or errors, it looks like the circuits are being > > > opened successfully. Any ideas why this doesn't translate to getting past > > > the ORPort being reachable test? > > > > If you're using a version of tor before 0.2.6.1, then it's possible that > > bug #13924 may be the culprit: > > https://trac.torproject.org/projects/tor/ticket/13924 > > "Reachability testing and channel is_local assume private addresses are > > local" (and therefore discount the local/private addresses for the purposes > > of reachability testing). … > I found the problem here: > https://github.com/torproject/tor/blob/cc10f13408e25eaf04f849d0f761680f383f… > > The check for channel_is_local returns true because my dev box has an > 172.16/12 address: > > https://github.com/torproject/tor/blob/725d6157df150ec9151450dc2422d9838c20… > > And thats what is keeping everything from working. The 172.16/12 block is a private address block. https://en.wikipedia.org/wiki/Private_network tor assumes that connections from private addresses are local. It doesn't update its reachability self-testing flag unless it gets a connection from a non-local address. This restriction is relaxed when TestingTorNetwork is set, as many test networks use private address blocks. > I commented out that > address block and now orport, dirport, and bandwidth tests are running. Commenting out a private address range is a dangerous change that has at least the following security implications: * "ExitPolicyRejectPrivate 1" won't stop clients exiting to the block you've commented out (warning, you have this set to the default, 1) * "ExtendAllowPrivateAddresses 0" won't stop clients extending to the block you've commented out (but you have this set to 1) * "DirAllowPrivateAddresses 0" won't exclude directory nodes with IPs in the block you've commented out (but you have this set to 1) As long as you trust your entire network, including any clients that can connect to any open ports, this should not be a problem. But please don't use versions of tor with this change on the public Tor network, you'd be opening yourself up to attack. It appears that my original fix to bug #13924 didn't anticipate anyone using "ExtendAllowPrivateAddresses 1" without "TestingTorNetwork 1". I'll submit a patch which swaps TestingTorNetwork for ExtendAllowPrivateAddresses. This will preserve the existing fix, because "TestingTorNetwork 1" implies "ExtendAllowPrivateAddresses 1". The relevant line is here: https://github.com/torproject/tor/blob/cc10f13408e25eaf04f849d0f761680f383f… In the interim, if you'd like a safer option, you could make the same code change to that line, or disable reachability testing entirely using "AssumeReachable 1". teor teor2345 at gmail dot com pgp 0xABFED1AC https://gist.github.com/teor2345/d033b8ce0a99adbc89c5 teor at blah dot im OTR D5BE4EC2 255D7585 F3874930 DB130265 7C9EBBC7

2 3

Re: [tor-dev] tor-dev Digest, Vol 51, Issue 34
by Rekha Tokas 23 Apr '15

23 Apr '15

Can I get the list of websites which are blocking tor traffic to view or edit their page ?? On 23 Apr 2015 17:30, <tor-dev-request(a)lists.torproject.org> wrote: > Send tor-dev mailing list submissions to > tor-dev(a)lists.torproject.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev > or, via email, send a message with subject or body 'help' to > tor-dev-request(a)lists.torproject.org > > You can reach the person managing the list at > tor-dev-owner(a)lists.torproject.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of tor-dev digest..." > > > Today's Topics: > > 1. Re: Experimenting with private tor setup (teor) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Thu, 23 Apr 2015 21:27:40 +1000 > From: teor <teor2345(a)gmail.com> > To: "tor-dev(a)lists.torproject.org" <tor-dev(a)lists.torproject.org> > Subject: Re: [tor-dev] Experimenting with private tor setup > Message-ID: <4942EA68-C681-4223-8A3B-A5E0C97E296F(a)gmail.com> > Content-Type: text/plain; charset="utf-8" > > > Date: Wed, 22 Apr 2015 23:14:07 -0400 > > From: CJ Ess <zxcvbn4038(a)gmail.com> > ? > > I think that just leaves a couple questions for now: > > > > - I know the directory authority's certificate needs to be > > renewed periodically (looks like 12 months default). Since it asked for a > > password that is something I need to do manually then send a HUP, > correct? > > Later on I'll try to hack generating a cert with days or hours of time > just > > to see what happens, but would like to know what the correct way to > handle > > it is. > > Yes, you will need to generate new authority certificates when they expire. > > Look at "man tor-gencert" for more details - you may be able to enter a > blank password, or generate a new certificate and send a HUP on a cron job. > Alternately, look at the chutney source code for how it's done there. (This > isn't my area of expertise.) > > > - All of my routers have done the bandwidth tests, but I see this warning > > on the DAs with each vote: > > > > Apr 22 22:39:41.000 [warn] Consensus with empty bandwidth: G=0 M=5 E=0 > > D=243 T=248 > > > > Is this something that will fill out as the uptime of the instances > > increase? Or is this something I should look into? > > I think you need to run a separate bandwidth authority to get bandwidths > in your consensus. This probably isn't necessary for your purposes, as your > instances are all on the same host. > > It's also not something that chutney does, and chutney networks function > fine. > > teor > > teor2345 at gmail dot com > pgp 0xABFED1AC > https://gist.github.com/teor2345/d033b8ce0a99adbc89c5 > > teor at blah dot im > OTR D5BE4EC2 255D7585 F3874930 DB130265 7C9EBBC7 >

1 0

Re: [tor-dev] Experimenting with private tor setup
by teor 23 Apr '15

23 Apr '15

> Date: Wed, 22 Apr 2015 23:14:07 -0400 > From: CJ Ess <zxcvbn4038(a)gmail.com> … > I think that just leaves a couple questions for now: > > - I know the directory authority's certificate needs to be > renewed periodically (looks like 12 months default). Since it asked for a > password that is something I need to do manually then send a HUP, correct? > Later on I'll try to hack generating a cert with days or hours of time just > to see what happens, but would like to know what the correct way to handle > it is. Yes, you will need to generate new authority certificates when they expire. Look at "man tor-gencert" for more details - you may be able to enter a blank password, or generate a new certificate and send a HUP on a cron job. Alternately, look at the chutney source code for how it's done there. (This isn't my area of expertise.) > - All of my routers have done the bandwidth tests, but I see this warning > on the DAs with each vote: > > Apr 22 22:39:41.000 [warn] Consensus with empty bandwidth: G=0 M=5 E=0 > D=243 T=248 > > Is this something that will fill out as the uptime of the instances > increase? Or is this something I should look into? I think you need to run a separate bandwidth authority to get bandwidths in your consensus. This probably isn't necessary for your purposes, as your instances are all on the same host. It's also not something that chutney does, and chutney networks function fine. teor teor2345 at gmail dot com pgp 0xABFED1AC https://gist.github.com/teor2345/d033b8ce0a99adbc89c5 teor at blah dot im OTR D5BE4EC2 255D7585 F3874930 DB130265 7C9EBBC7

1 0