- tor-dev - lists.torproject.org

working back to socks_request_t
by CJ Ess 03 May '15

03 May '15

So I'm doing a bit of an experiment, the idea being that if you have a group of tor users sharing common infrastructure then its a slightly different situation then one lone user, and you wantto emphasize that resources should not be shared, caching should be minimal and non-persistent, you need to keep usage from standing out, etc. The problem with my original idea is that everything that does HTTP <> SOCKS is one or two decades old, and draws a lot of attention because it forks for every connection or is some strange process that nobody has ever seen before. So plan B is everyone involved runs their socks speaking browser on their desktop/laptop, everyone runs a tor client on the same device as their browser, we use the HTTPProxy/HTTPSProxy feature of the clients to navigate the firewall, everyone uses their own credentials instead of having one ID draw attention for high utilization, and the presence of the Proxy-Authorization header takes care of any caching/session sharing issues along the way. To make that work, the one question I have for tor-dev is if its possible Here: https://github.com/torproject/tor/blob/24f170a11f59e26dec3a24d076b749c8acc7… To work back to the socks_req, so that I can pass through the username and password to the upstream proxy instead of the one global username/password?

1 0

onionoo: historic details.json data
by Nusenu 02 May '15

02 May '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi Karsten, can one download historic onionoo documents (details.json) archived somewhere or would one have to setup onionoo + feed old data into it to achieve that? thanks, Nusenu -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJVIaqIAAoJEFv7XvVCELh0OQgP/3FiBM3uMifPW9A0u8sMuh1E 7iFDmU52MNmkeToBUnuxuUK+7ig96tz/p5Ds6OyaAtC0Ld/IzRlIU5ELjqDwRqMD LPaafWm21QHO8y4fgW5FfGDfFTeLL/b3Lm1E9VmJ8wpOsgpzNnBMUoeDrpDyE3Ow zHXM/IfCSROqmO9lOeU6YGQTwInucc0HSveAWQ9i/x6iks9kMguzGnuWTxgfwA61 RQT4KUKZI+b5w//8V3/IpR5jlQ2N4OJrURpVhaKKNYMy+mqOfl5/a1ZPyQhhDaxj eLfg0qQmsk9IJY/6dZa0XogsmAzRCcEO/Ha0b0ZoiWs+VFo97cczoWdVWHoKpsyS X/qeehkOS13l22mw8va+yuj4zoRBrgK2chzcG2iPgVBeTu1H7B+x57PQrQXaCdaf rq8wwlS7mgaMQ6mgHyOQ1niZDTnvJaY0e3gVsgucR7YOTdALxnnHhQkyNboCWq/E 180SetWZfIHbL3cV38DRxYKzijwSu1gqmkwTJWffylb5SMja1TdW9cCq/RzidqyF v7vLXHQwmrRQ0XOy9UULe5XtU0Fe4YCm/zMNzBHHGIrePd664mYKqqXP2dlempwb BbbVgMLuFC2sy2eqxtwyQrrDUoWrEovUxg/BeoKO8RYXzNhPtha8eQkAhexhNux2 2mosesv/fooaQnt17qAo =q6LM -----END PGP SIGNATURE-----

6 16

#14995: systemd unit files - review
by Nusenu 02 May '15

02 May '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi weasel, following your comment [1] about your plans to use systemd instead of init.d scripts I prepared unit files [2] - tested with debian jessie. Would be great if you could comment on them. Since it feels a bit as if I would use the wrong communication channel (trac), please let me know if I should move this elsewhere. thanks, Nusenu [1] https://trac.torproject.org/projects/tor/ticket/14995#comment:14 [2] https://trac.torproject.org/projects/tor/ticket/14995#comment:24 https://github.com/nusenu/tor-multi-instance-initscripts/blob/master/debian… https://github.com/nusenu/tor-multi-instance-initscripts/blob/master/debian… -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJVFqosAAoJEFv7XvVCELh0AjgQAIlLflC6f+mqUUiAyvQsTO/4 +fNK1MBFUNJUpEws3gqD/3OQfBnhuV9Po4SiRMPfQo0IHuLSB0jNHslOexVBWzpY s4ypeNAH+Eu58Pomexo9xOMCZTmM7Jmhm8HdCodSXBMSKlK1jMwqqmRRQDnijf3T hYos6yeJydwXnV2yDaeF6AOiuAzIQC2s+Mwu+tynX3ETCIyDzsDcQEOaDiwnmWBX 76kIqz0sF0N7tOeMiLoMvK1J9HhW+sMH4aaGwZFXPCMLEpziIB5spEmgvpa+SoQ0 dG2q3Hd7ryBaac/KSeX/Dyidur8LxheA9slVqwkdcorXWBdQd7Xnom2WTOs/2cSf Dy3ZFJD1vi3/y6Gq0DsWY3Z4XhPPs4gTVOL056Xc/GyZXmPvAVI5mk8EdtU7ezbu NxXqjVoEcX59IWhyMOjh2eaeEZvaxmyfP38ek2f6nH5pZv9FtmjKZ61LwYtL8qJx wEn+qIVXy1Zl+qU/NhUpMeUqn029Ci+mL+6x/JfNpaka81Rtqsb+6SKQQwPwGGu7 2SwsDjM+B6YsWSf3niL3rp23XWaT1mM830QBnTrMpE+kht/4b1ytgs7NV72E30+5 Ibi5y/F/TkTc6yExJd1qxKkpXY0gnEWIgf0l4ik5FOD3DK47lQgKYg4feAcPxLUo qFDT5Y0Fnhezh5DVnRp+ =mtYl -----END PGP SIGNATURE-----

3 5

Released BridgeDB-0.3.2
by isis 02 May '15

02 May '15

Hello all, Yesterday I released and deployed BridgeDB-0.3.2, which has several major fixes and changes. Major changes visible to users include: changing the default pluggable transport to obfs4, and users requesting bridges will note that they are again normally receiving the maximum number (3) of bridges. The temporary decrease in bridges was due to the fact that, while rewriting BridgeDB's bridge descriptor parsers (#9380), I implemented full verification of all cryptographic data involved, including signatures and descriptor digests, in order to validate the chain of bridge information from the networkstatus document (produced by the BridgeAuthority), to bridge server-descriptors, and finally to bridge `extrainfo` descriptors (which contain information on a bridge's pluggable transports). This turned out to be somewhat of a bad idea, because the BridgeAuthority appears to not producing good networkstatus documents (see #11216, #12254, #15707, and #15866). Changes in version 0.3.2 - 2015-05-01 * FIXES a problem with the calculation of Levenshtein distances between blacklisted email addresses and those on incoming email. This fixes a problem with the fuzzy matching implemented in #9385: https://bugs.torproject.org/9385. * FIXES #1839 https://bugs.torproject.org/1839 BridgeDB's distributors now rotate their hashrings at configurable scheduled intervals. * FIXES #4771 https://bugs.torproject.org/4771 BridgeDB now records which of the HTTPS Distributor's sub-hashrings are used for clients coming from Tor Exit nodes and other known proxies. * FIXES #12504 https://bugs.torproject.org/12504 Which Pluggable Transports BridgeDB distributes is now easily configurable via the bridgedb.conf configuration file. * FIXES #13202 https://bugs.torproject.org/13202 Old bridges running Tor-0.2.4.x with Pluggable Transports like scramblesuit and obfs4proxy have a bug which causes them to not include the PT arguments in the `transport` line they submit to the BridgeAuthority in their extrainfo descriptors. This causes BridgeDB to have broken bridge lines for these bridges. For example, scramblesuit requires a `password=` in the `ClientTransportPlugin` for clients to connect to it. If BridgeDB receives a line in that bridge's extrainfo which says `transport scramblesuit 1.2.3.4:1234` (without a password), then when BridgeDB gives clients a bridge line for that bridge, it'll look like "Bridge scramblesuit 1.2.3.4:1234" - meaning that it won't work. This fixes the issue by excluding broken transports from being distributed to clients. * FIXES #15517 https://bugs.torproject.org/15517 For all clients who are coming from IPv6 addresses and are not using Tor, who go to https://bridges.torproject.org, BridgeDB now groups these clients together by /32. This "grouping" causes all IPv6 clients within the same IPv6 /32 to get the same bridges. Previously, BridgeDB grouped IPv6 clients by /64 (which is ridiculously small, considering standard IPv6 allocation sizes). For all clients who are coming from IPv4 addresses and are not using Tor, BridgeDB now groups these clients together by /16. Previously, BridgeDB grouped IPv4 clients by /24. (This latter change was technically made as part of #4771.) * FIXES #15464 https://bugs.torproject.org/15464 The setup procedure for creating a BridgeDB Continuous Integration build machine is now simplified and generalised to include build environments like Jenkins, not just TravisCI. * FIXES #15866 https://bugs.torproject.org/15866 BridgeDB now ignores nearly all the information in the networkstatus-bridges file created by the BridgeAuthority. * ADDS benchmark tests to BridgeDB's test suite, and some of BridgeDB's algorithms have been revised to improve their speed. As per usual, the full CHANGELOG is available here: https://gitweb.torproject.org/bridgedb.git/tree/CHANGELOG -- ♥Ⓐ isis agora lovecruft _________________________________________________________ OpenPGP: 4096R/0A6A58A14B5946ABDE18E207A3ADB67A2CDB8B35 Current Keys: https://blog.patternsinthevoid.net/isis.txt

1 0

what capabilities does tor need for reloading?
by Nusenu 29 Apr '15

29 Apr '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi, 'systemctl reload tor' fails due to hardening restrictions in tor's systemd service file [1]: CapabilityBoundingSet = CAP_SETUID CAP_SETGID CAP_NET_BIND_SERVICE Removing that line "solves" the reload issue. Reloading with that line does not generate any tor debug loglines. What capability would one have to add to the list to make it work with CapabilityBoundingSet? thanks, Nusenu testing with: tor 0.2.6.4, jessie/systemd 215 [1] https://gitweb.torproject.org/tor.git/tree/contrib/dist/tor.service.in#n26 -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJVCVA7AAoJEFv7XvVCELh0bWIQAKfDZdhwrcWzwOHEP/o3FMoa BTkMxjHdEDezlaHd61/XWHC1cYNOi6kqe/xGL1HRMtDwl09tbn3lq0Vty9P9hBP5 ucLaS1Izz0w7VprEd4ZK+/G4pV8Ht6Kjd7LSaV8RsjdCfK9g5WaI/IDIVGbYKUnC NVJxY+XCxZsvMmkfCUo1un6yZ/p0eQEfksDwtDvf7EupIy3o5wYJhM1bcvVzm/3H UenP8t8VBb7TVOBRuZUyMzS173db/SKp2tY1IOiUktzyJqzzck8gPJvQ4l8DoeqM E2yVr+Qvex/IXRx379sJTyBJt9xthC9BS91uUJA0G3dbYVSvRoUN5XDjaqYztSN3 ctkjT3cocLDu43EslGo/Egh+xWTMdnTvcaTIoLkD5IN4FWu3IrjWnG0gOOyNyPf5 F4UfCty5xn9ztb0y7Zf2GOliR9CnkSB8PIuMt4ManvrMGOwYPZw1KsGsc49UYadn XhEUj1uzf3FBZw2LmbiBR5lNGX2WanWt83EwkiH03MsBkouD60+D/RJ5UQ8pVEwm JHLBqbT2GtBCda3OIPec1kdh3P5TFF+aN9aC1HkVsYRwoUJtIjxPg3wkrOVCU4VF ZJVbqlVuJQn8/3GnphkQgt+jJqTl3b4Ttksu+omGJgYU2Wu42VNFvCFraeQ75q4J D1NinH/G/3I3KBYP+JNu =/eJ6 -----END PGP SIGNATURE-----

3 6

Re: [tor-dev] shipping with fallbackdir sources
by teor 28 Apr '15

28 Apr '15

> > Date: Fri, 17 Apr 2015 18:56:01 +0200 > From: Peter Palfrader <weasel(a)torproject.org> > > Hi, > > so, Tor has included a feature to fetch the initial consensus from nodes > other than the authorities for a while now. We just haven't shipped a > list of alternate locations for clients to go to yet. > > Reasons why we might want to ship tor with a list of additional places > where clients can find the consensus is that it makes authority > reachability and BW less important. > > At the last Tor dev meeting we came up with a list of arbitrary > requirements that nodes should meet to be included in this list. > > We want them to have been around and using their current key, address, > and port for a while now (120 days), and have been running, a guard, and > a v2 directory mirror for most of that time. > > I have written a script to come up with a list of notes that match our > criteria. It's currently at > https://www.palfrader.org/volatile/fallback-dir/get-fallback-dir-candidates > > It currently produces > https://www.palfrader.org/volatile/2015-04-17-VjBkc8DWV8c/list > > Discuss :) Peter, your list only includes the IPv4 addresses of the directories. Can you include the IPv6 addresses as well, like: https://trac.torproject.org/projects/tor/ticket/8374#comment:8 If we can get a list we're happy with, I propose we distribute them in a similar fashion to the geoip file, a flat file provided with the distribution. This would require a torrc option for the location of the file. (I don't think signing the file has a specific threat model: the list of directory authorities themselves could almost as easily be modified in the code before a build.) Do we need to contact the operator of each directory mirror for permission? 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

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