- tor-dev - lists.torproject.org

txtorcon suports "tor:" endpoint
by meejah 19 Jun '15

19 Jun '15

I (finally!) merged David Stainton's "tor:" endpoint parser to txtorcon's master. This means two things: txtorcon now depends on txsocksx and you can do "client-type" things directly with endpoints, such as connecting to txtorcon's homepage: ep = clientFromString("tor:timaq4ygg2iegci7.onion:80") ep.connect(...) If anyone has strong feelings about txsocksx, I could be convinced to make the dependency optional (so you'd only get the "tor:" endpoint parser etc. if you happened to have installed txsocksx). Let me know! Note that the last released version of txsocksx doesn't work with Twisted 15.0.0+ but there is a fix on master which does... -- meejah

1 0

Re: [tor-dev] The future of GetTor
by teor 18 Jun '15

18 Jun '15

> > Date: Mon, 15 Jun 2015 20:14:54 -0300 > From: ilv <ilv(a)riseup.net> > > Hi people, > > … > > With this in mind, we have been discussing about the idea of having a > signed and verified distributor app (desktop), available on official > channels (OSX app store, Google Chrome store, etc), which could ease the > process of downloading and verifying the integrity of Tor Browser. In > other words, a user should be able to download and make sure it has the > right file with just a few clicks. However, we have different thoughts > on how this should work: > > * Option 1: GetTor should work as a backend and have an API. The > distributor (and even other apps) would send queries to this API asking > for links. The problem with this is that if Tor Project's website is > blocked, is quite possible that the API would be blocked too (e.g. > gettor.torproject.org) > > * Option 2: The distributor is in charge of presenting various > alternatives to the user and getting the files directly from the > cloud/hosting services. > > So, the purpose of this email is to get feedback from the community, and > my specific questions to you people are the following: > > 1) What do you think of the distributor idea? It is something you or > others would want? The distributor sounds like a great idea, but, with Option 2, the user should always be able to fall back to actual links to the cloud services (wherever possible). This allows users who have trouble with the automated download to retry later, perhaps at a different location, or with a different browser. > 2) In case we develop the distributor, should the email autoresponder > remain? I'm a big fan of diversity in distribution methods, but there are only a limited number of software maintainers… > > 3) If you agree on developing the distributor, what option you think > would fit better? (please suggest better options) If the distributor is a backend (Option 1), it would help to have mirror(s). But I wonder if we are just re-creating a single point of failure, and would be better using a CDN. It would be a terrible experience to succeed in downloading an app, only to find that the distributor was blocked. Is it possible to submit an app to the app stores (I am thinking Apple's restrictions, here) that would bootstrap a Tor Browser download over the Tor network? For example: 1. Download app 2. The app has various CDN links (or a way of getting them) and a some predefined bridges 3. The app tries the CDN links and bridges in order of reliability / expense 4. If the links or bridges fail, the user gets advice on how to find new, uncensored links or bridges and input them. 5. App downloads and verifies Tor Browser using the CDN or the Tor network In most cases, the user experience would be one-click: 1. Open the app 2. See a recommended option highlighted out of a list of working options 3. click download 4. see a progress bar 5. Get a verified Tor Browser 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 1

Hidden Services and IP address changes
by Martin Florian 16 Jun '15

16 Jun '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello everyone, I think I've found one or more bugs that appear when Tor clients hosting HSes change their IP address during operation. I'm slightly overwhelmed from reading the Tor source code and not sure how to best fix them. The central issue that I discovered can be reproduced like this (assuming Tor clients A, B and C): 1. (Setup) A hosts the HS X and A, B and C are all booted up. 2. B connects to X - it works! 3. A changes its IP address. 4. B tries to talk to X again - doesn't work! 5. C tries to talk to X (for the first time) - works like a charm (so X IS working) I digged through the Tor log and source code and have now arrived at following hypothesis for why this particular error happens: - - after A changes its IP addresses, it never establishes a circuit to the old RP with B again. - - B, on the other hand, keeps trying to talk with A through that RP, saying that it is an "Active rendezvous point". B never stops trying to use that RP. So, they appear to be two sides to this: a) A not notifying B or the RP about its IP address change. b) B not considering the possibility that the RP might not be active anymore. b) seems easier to fix. Some logic needs to be included for forgetting about RPs that have failed once. I identified connection_ap_expire_beginning() as one potential place to do this. Am I on the right track? Is this a good idea? And how do I forget about RPs? These are some of the questions I'm struggling with... I should also probably open a bug report, but I thought I might first ask for some advice here. Thanks, Martin PS: Why this is important: HSes/Onion services running on mobile devices will very often have to deal with IP address changes. I'm thinking about applications like Briar or our own hacky attempts to enable generic P2P application development on top of Tor hidden services (https://github.com/kit-tm/PTP) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJVXb5wAAoJEK5sDRyGnIFfbbYP/1gi6A/wZFhQfr6IRG4F1jBT c2/euGqiLG1rrqh5inTzrSIrHU0cm6FBxrtfB4egUO8+saVouhDrsgVQIF/y7nK0 f754Bcx9w3/a9hDK3L0iUtsYguMMTPOeWeCCdAxblYZWhKF3bxu9qwVsNqtVUUIm Oz1WLl4N++Pf9v09LRaDR7JaL9Ts7aJ3sEIWLjuntgEoS9sJaWmUjdVZZCjdWAOF S2FM6O1SE2V8xiMFjFOEmabWYUigrVZu2qk9/XpWeMDeNNIT57URZ2R0gKxjxLEl c5/+KawvSFGVKeoyTM+xys3UcO2IvnKxL43M2pocO5UX9TZv0iyrx1YRoTPEq3D5 HoOEX3Q0wlk6aJ3qqGFb2nNwr4n18k4IvdopCPkGvMBUuflcD77ug42k7TDEgXWD yJqBfxQE8l+p7QZ+kpHajdSmMtKzdjbYyuA4l1/FUskHQfX1fg2WyHQSdZR9Dxni GZJdnHOdN6f5T2lUVCuP4ZWlkHJ/HEPYWT7BOxRwyCbI6ViHZUIqJA8q1EPYGwP5 MOkSsx4diFS+RxAxb/vcudalOT8gIuszYsUImM1o2yzSpZ1faBuv1WCbdQ4qVcm8 XUrxSJCrX6qaY/ZxovWWnggYK9w2CgLDEHfeY39VRwLjDiOi85JWhGBvvtyGb84v WJvzKA4thqQ+JQEsR24+ =JxdI -----END PGP SIGNATURE-----

2 1

Re: [tor-dev] Hidden Services and IP address changes
by Nathan Freitas 15 Jun '15

15 Jun '15

On Thu, May 21, 2015, at 07:16 AM, Martin Florian wrote: > I think I've found one or more bugs that appear when Tor clients > hosting HSes change their IP address during operation. I'm slightly > overwhelmed from reading the Tor source code and not sure how to best > fix them. Thanks for bringing this up. I know Michael from Briar has definitely focused on solving this at some point, and Yaron from the Thali Project (who build this library: https://github.com/thaliproject/Tor_Onion_Proxy_Library) as well. I've been implementing an OnionShare-type app myself, and had hoped this was solved by some recent changes, but it seems not, from your experience. > The central issue that I discovered can be reproduced like this > (assuming Tor clients A, B and C): > 1. (Setup) A hosts the HS X and A, B and C are all booted up. > 2. B connects to X - it works! > 3. A changes its IP address. > 4. B tries to talk to X again - doesn't work! > 5. C tries to talk to X (for the first time) - works like a charm (so > X IS working) > > I digged through the Tor log and source code and have now arrived at > following hypothesis for why this particular error happens: > - - after A changes its IP addresses, it never establishes a circuit to > the old RP with B again. > - - B, on the other hand, keeps trying to talk with A through that RP, > saying that it is an "Active rendezvous point". B never stops trying > to use that RP. I wonder if B also was running a hidden service, if it would be possible at the application level for A to tell B that it has changed IP addresses, and then through some interaction with the Tor Control Port, to fresh the RP? > So, they appear to be two sides to this: > a) A not notifying B or the RP about its IP address change. > b) B not considering the possibility that the RP might not be active > anymore. > > b) seems easier to fix. Some logic needs to be included for forgetting > about RPs that have failed once. I identified > connection_ap_expire_beginning() as one potential place to do this. Am > I on the right track? Is this a good idea? And how do I forget about > RPs? These are some of the questions I'm struggling with... > > I should also probably open a bug report, but I thought I might first > ask for some advice here. I think there is a bug report somewhere, but I am not sure the exact number or state of it. > PS: Why this is important: HSes/Onion services running on mobile > devices will very often have to deal with IP address changes. I'm > thinking about applications like Briar or our own hacky attempts to > enable generic P2P application development on top of Tor hidden > services (https://github.com/kit-tm/PTP) Definitely an important topic. +n

3 2

[Onionoo] When is the system property onionoo.cron.runonce set?
by l.m 15 Jun '15

15 Jun '15

Hello, So I've been playing with Onionoo's source and I cannot find where this property is set. When the main class for the cron updater runs it checks for the property existence and returns a string "true" if not found or unset. This "true" is used to evaluate the first time update. I cannot see where the property is updated and so I get one-time updater each time. I can add the code to set the property, and all's well, but I wanted to check to make sure I'm not missing something. I cloned from the git repo. Thanks --leeroy

2 1

Sanitizing bridge descriptors containing ed25519 fields
by Karsten Loesing 13 Jun '15

13 Jun '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Forwarding from a private thread with Nick. - -------- Forwarded Message -------- Subject: Re: Whoops Date: Fri, 29 May 2015 21:20:57 +0200 From: Karsten Loesing <karsten(a)torproject.org> To: Nick Mathewson <nickm(a)torproject.org> Ugh, long mail ahead. This turns out to be more difficult than expected... On 29/05/15 19:29, Nick Mathewson wrote: > On Fri, May 29, 2015 at 11:04 AM, Karsten Loesing > <karsten(a)torproject.org> wrote: >> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >> >> Sure! >> >> My main question is which of these new fields we'll have to >> sanitize in bridge descriptors. >> >> The current idea of sanitizing bridge identities is that Tonga >> would give out server descriptors if you give it a bridge >> identity. We want to avoid that, which is why we're SHA1()'ing >> fingerprints and removing cryptographic material. >> >> What about the new identity? Would we have to sanitize that in >> any way? And if so, would we want to SHA1() it, or is there a >> more ed25519y way to do this? >> >> I guess the better question might be: are there plans for Tonga >> to give out descriptors if you tell it an ed25519 identity? If >> not, do you see any potential trouble in leaving it unchanged in >> sanitized bridge descriptors? >> > > I would suggest that we sanitize all the crosscert stuff, and the > ed25519 identity, and the ed25519 signing cert. Does this need to > be done using some language I know? If so I'll be happy to hack > it up for you if you point me to the current code that does it. Thanks for the offer, really, but if I can, I'd rather want to write this code myself once I know what it's supposed to do. The reason is that setting up this code and providing you with sample data might be more effort than writing it myself. Hope that's okay, too. Only if you're curious, here's the current code that sanitizes bridge descriptors: https://gitweb.torproject.org/metrics-db.git/tree/src/org/torproject/ernie/… But feel free to ignore that code, and let's talk conceptually or by example. > (The authority might someday give out bridges based on this > information. Who knows? Not me. Better to be safe than sorry > IMO.) Okay. > To sanitize an ed25519 identity, i'd suggest SHA256. Best avoid > SHA1. Sure, that would work. By the way, here's how we're currently sanitizing bridge descriptors: https://collector.torproject.org/formats.html#bridge-descriptors Following those steps, I'd do the following things (quoting an actual bridge descriptor as input here; edit: scrubbed potentially sensitive fields, sorry for the linebreaks!): > router euler [scrubbed] 8000 0 0 identity-ed25519 -----BEGIN > ED25519 CERT----- [scrubbed] -----END ED25519 CERT----- Base64-decode that block, throw it into SHA256(), base64-encode the result, format as block. But wouldn't the result be much shorter? There's no new "fingerprint" equivalent, like "fingerprint-ed25519", is there? Whatever we do here, we should make it simple enough for bridge operators to do, too, if they want to look up their bridge in Atlas or Globe. hex-encode(SHA1(hex-decode(fingerprint))) seemed okay. We should try to find something similar for ed25519 identities. (We could also have tor log its "hashed ed25519 identity", but that only works for people looking at logs.) > platform Tor 0.2.7.1-alpha-dev on Linux protocols Link 1 2 Circuit > 1 published 2015-05-29 17:53:38 fingerprint [scrubbed] uptime 2 > bandwidth 14971520 104857600 63488 extra-info-digest [scrubbed] > [scrubbed] IIRC (and it's been a while...), I'd replace E07A... with its SHA1. So, I guess I'd replace YZpo... with its SHA256. Note that the extra-info descriptor would contain a "router-digest" line with the SHA1 of E07A... and be stored in a file using that identifier. In the distant future, we'd probably store extra-info descriptors under their SHA256. > onion-key -----BEGIN RSA PUBLIC KEY----- [scrubbed] -----END RSA > PUBLIC KEY----- signing-key -----BEGIN RSA PUBLIC KEY----- > [scrubbed] -----END RSA PUBLIC KEY----- onion-key-crosscert > -----BEGIN CROSSCERT----- [scrubbed] -----END CROSSCERT----- I'd remove the last six lines starting at "onion-key-crosscert". (The "onion-key" and "signing-key" lines/blocks would also be removed in the current code.) > ntor-onion-key-crosscert 0 -----BEGIN ED25519 CERT----- [scrubbed] > -----END ED25519 CERT----- That block would go away, too. > hidden-service-dir contact [scrubbed] ntor-onion-key [scrubbed] > reject *:* router-sig-ed25519 [scrubbed] I > guess that can go away, too. We'll probably want to put in a "router-dig-ed25519" with the SHA256 of that value. > router-signature -----BEGIN SIGNATURE----- [scrubbed] -----END > SIGNATURE----- And here's the corresponding extra-info descriptor: > extra-info euler [scrubbed] identity-ed25519 -----BEGIN ED25519 > CERT----- [scrubbed] -----END ED25519 CERT----- Same as above, whatever that will be. > published 2015-05-29 17:53:38 write-history 2015-05-29 15:36:42 > (14400 s) 2461696,2649088,1583104,1612800,1871872,2102272 > read-history 2015-05-29 15:36:42 (14400 s) > 7444480,6047744,5960704,8019968,4823040,6364160 > dirreq-write-history 2015-05-29 13:36:18 (14400 s) > 1180672,28672,618496,28672,14336,589824 dirreq-read-history > 2015-05-29 13:36:18 (14400 s) 0,0,0,0,0,0 geoip-db-digest > 0A1F9C09E08F6F2490E8880664D4E863D1680A12 geoip6-db-digest > A6E9B5DE6F887315749B29F9C9F698215BE5240A dirreq-stats-end > 2015-05-28 19:28:08 (86400 s) dirreq-v3-ips co=8,tw=8 > dirreq-v3-reqs tw=16,co=8 dirreq-v3-resp > ok=16,not-enough-sigs=0,unavailable=0,not-found=0,not-modified=0,busy=0 > > dirreq-v3-direct-dl > complete=0,timeout=0,running=0 > dirreq-v3-tunneled-dl complete=12,timeout=0,running=0 transport > obfs3 [scrubbed]:54997 transport scramblesuit [scrubbed]:55749 > password=[scrubbed] transport fte [scrubbed]:7331 bridge-stats-end > 2015-05-28 19:28:17 (86400 s) bridge-ips co=8,tw=8 > bridge-ip-versions v4=8,v6=0 bridge-ip-transports <OR>=8,obfs3=8 > router-sig-ed25519 [scrubbed] Same > as above, whatever that will be. > router-signature -----BEGIN SIGNATURE----- [scrubbed] -----END > SIGNATURE----- So, uhm, I realize there are quite some open questions above. Hope you have some ideas, otherwise I'll think more about this tomorrow. Thanks! All the best, Karsten -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJVaMrAAAoJEJD5dJfVqbCrJC8H/j279ZhNydUoYA6aWEuZVD9P 5ERo5C+93UMhBBJLtyOmKXSBFso/wUgo1i1XwU79n6wyxxu3D8GfVnSJGhiLdEtn S6eDKkf4S/iPs+cBD8FYY/cMaj+lIehepRvzwlwV1BGSTubJXNMQTKgdh11urRTq lcxrQQNheQlQwx2ekqnTzFNDRvBVwuEGNH6GneG/0aQi4Jv4F3vkPVvOnXJz3z0u OrlhVPFp71BqkciIzv4yBEdxepXarX2zugxnLiKj0hmb6aCrM7NhjElfeoRkqeq4 ws6f997AJD6PJK97fTTTk+IaLAD6u0TtwXZv0v49On/ISSr61VU0CrJ39sCmY04= =JdbV -----END PGP SIGNATURE-----

2 7

Fwd: [PATCH]: Add Dockerfile
by Jessie Frazelle 13 Jun '15

13 Jun '15

Hi! I made a patch for running tor and/or the tor development tests in a Dockerfile. Attached is the patch and if approved you can pull from https://github.com/jfrazelle/tor.git, branch: add-dockerfile This would make running the tor test suite as easy as: docker build -t tor . docker run tor make check You can also run tor with: docker run tor Thanks! -- Jessie Frazelle 4096R / D4C4 DD60 0D66 F65A 8EFC 511E 18F3 685C 0022 BFF3 pgp.mit.edu -- Jessie Frazelle 4096R / D4C4 DD60 0D66 F65A 8EFC 511E 18F3 685C 0022 BFF3 pgp.mit.edu <http://pgp.mit.edu/pks/lookup?op=get&search=0x18F3685C0022BFF3>

1 0

design for a Tor router without anonymity compromises
by coderman 12 Jun '15

12 Jun '15

a friend and i are working on a Tor router design that doesn't compromise anonymity for convenience. [0][1][2][3][4] we're soliciting feedback as part of a go / no-go decision on continuing this effort. in particular, the design is intended to meet the scrutiny of Nick M., Roger, and Mike P. as the focus on support for Tor Browser and Tor on each client indicates. --- the design and prototype code is marked "copyright Tor Project Inc. by assignment", which means that we're using a notary public to formally assign copyright ownership to the corporate entity "Tor Project, Inc.". your comments will be taken into consideration, however, please defer patches / code contributions under other owners (you) until assignment complete. --- last but not least, we're trying to eat our own dog food. all of our planning, development, and operations use hidden services, called Onion services in the document, and this bootstrap is more difficult than expected. [5] please provide feedback in reply on this thread or to me directly.[6] assuming the project continues, we will have Onion services to support collaborative development up soon. best regards, and my thanks in advance for your scrutiny! 0. "Tor Enforcing Privacy Router" http://serqet345qt265xp.onion/ 1. "Op-ed: Why the entire premise of Tor-enabled routers is ridiculous" http://arstechnica.com/security/2015/04/18/op-ed-why-the-entire-premise-of-… 2. "[tor-relays] Anonbox Project - Mike Perry" https://lists.torproject.org/pipermail/tor-relays/2014-October/005541.html 3. "[tor-relays] Anonbox Project - Roger Dingledine" https://lists.torproject.org/pipermail/tor-relays/2014-October/005544.html 4. "[tor-talk] Cloak Tor Router (thread)" https://lists.torproject.org/pipermail/tor-talk/2014-November/035436.html 5. "Onion services" came in behind "Tor sites" because sites felt too web browser focused. we're trying to avoid the legacy "hidden services" nomenclature. 6. i have a long history of extreme dislike for encrypted email, key servers, web of trust, and other moral hazards. however, if you encrypt to my key you can send private mail, if desired. note that some encrypted email clients will fail insecure if the intended recipient doesn't match a keyring identifier! https://peertech.org/keys/0x65A847E7C2B9380C-pub.txt

5 11

[Onionoo] Resource requirements for serving static data
by l.m 11 Jun '15

11 Jun '15

Hello, When I check the running Onionoo server at onionoo.torproject.org I see it is using Apache. In the installation documentation running the web service starts the embedded Jetty. The first question I have is: which is responsible for the static components of the official Onionoo server? Does the running Apache serve (or cache) the static data or just forward to the embedded Jetty. Thanks --leeroy

2 1

Re: [tor-dev] Adding a NotDir router status flag
by teor 09 Jun '15

09 Jun '15

> Date: Fri, 29 May 2015 14:24:33 +0300 > From: s7r <s7r(a)sky-ip.org> > > Signed PGP part > Hi Matt, > > Nice to hear there's ongoing work for this proposal. > > I also see the NotDir flag as useful for migration, because for quite > some time after prop 237 is implemented we will still have relays in > the consensus which will have DirPort open (separate from ORPort). A > client needs to know to make directory requests on DirPort for the > relays with V2Dir flag, and know to make directory requests on ORPort > for the relays which only have ORPort open and NotDir flag. > > > After (hopefully) medium time we can drop the V2Dir flag (we are way > passed from V2 directory anyway) and after longer time we can also > drop NotDir. I guess this depends if directory requests on ORPort will > be only implemented in new Tor releases or also backport? It's unlikely we'd backport a feature of this magnitude - we already ran into issues (mainly with hidden services) when the authorities assumed that relays with only an ORPort would answer directory requests, but the relays weren't actually doing so. > I guess we > can say it's safe to drop both flags when over 95% of the relays > respond to directory requests on ORPort. We will just need Valid flag > to make sure we can separate the relays which try to poison directory > data. When relays have AccountingMax set, they disable their DirPort to maximise the bandwidth used for relaying Tor cells. This implies that they should also ask for the NotDir flag, and refuse to respond to directory requests on both the DirPort and ORPort. (We don't want relays that are already bandwidth-constrained receiving directory requests that we know they'll refuse - this is a waste of their bandwidth.) Does this need to be part of prop 237? Since the NotDir flag is still useful in with AccountingMax, we should reconsider the plan to drop NotDir in a few releases' time. 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 1

Paper on domain fronting (meek)
by David Fifield 09 Jun '15

09 Jun '15

I and my colleagues at Berkeley, Lantern, and Psiphon wrote a paper on domain fronting, the censorship circumvention technology that underlies the meek pluggable transport among other systems. It's going to appear at the PET Symposium on June 30, 2015. If you've been following along, you know most of the story for Tor, but the paper also includes the story of deployment on Lantern and Psiphon. I'm trying an experiment. Normally this kind of paper is published as a PDF. I find it annoying to read PDF papers on the web, where you have to scroll to the end to find URLs for references (if you're lucky). So I made an HTML version of what's going to get published in the proceedings. https://www.bamsoftware.com/papers/fronting/ I have to admit, though, that PDF is nice for printing out and reading offline, so here is the PDF version: https://www.bamsoftware.com/papers/fronting.pdf

1 0

additional triggers for DocTor?
by nusenu 05 Jun '15

05 Jun '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi Damian, does DocTor's design allow for triggers that alert if a certain amount of relays signed up within one day or within a week (instead of within one hour)? Another trigger could be the last_restarted timestamp. If that makes sense I would file feature requests on trac and provide some possible thresholds. Example of an event that would trigger then (2015-04-01): https://lists.torproject.org/pipermail/tor-talk/2015-April/037384.html -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJVcdCSAAoJEFv7XvVCELh0l5IP/R0NeXImuchqastZcg4T4PK7 Qy5VmFrWBdG9AOnypxIMgzVF5/M+hKjRgbbAp9/VrRXqpbFCgnChnQvqyJcW1nB0 AYGfqEUfavTBthbtTfq6g43BLBZke0olBMVFlKHaAYTidXMabrY0OlZ3QjdHt1Sx DovQ/zGVX263VR1YZimXom1xokCDm7J51vPURjx9BLrBQ2zdEGvOWWwdT+w1CiaK iH4I0AGUPZfLxxLU7rCorFAIV2AyKTT97EN9lQlD3TtPmoDiZdhPthR2MRKVruEP 3Kt76VDMRPro6oKo2d3sk5UFuyh0Hg+yqJhTJhjdZ0w/ZQtbIjlkHbnfSqgthEPL fi2XKQrX1BSfbQpsig70FRFHgKEQVzplXLlca9o1sn52GrwdY8fzNLc0p8xZiFSc xoognuyER4IgLP10c2QsYSoCx50yfpYOxDZIEFVIelDDKGIqVQzR/rGRwBfXBcn/ 598SPhka+h0BK/NudG/k5qRlsdWpQdygeAfDBUUO6AxHaIH2P96Pe1CfxNkoMGX4 TWZ2+pTXye6wdiFhdhDYGPuCtmOgI5GQ5alHEvsk3s7/n0YitRRNHNiNe3SGw7UN hX6HQuWmxD5J/D1fcj5gC/gJZxkeluTRO6iOP1AoNAqP9XGgQeT7uwhL+FzT65V5 GlMIH20AeBn2FWIesaxf =Ia4Q -----END PGP SIGNATURE-----

2 1

Re: [tor-dev] onionoo: bug in family set detection?
by saitosean＠ymail.com 05 Jun '15

05 Jun '15

I ran some tests to investigate said onionoo bug. My test case is simply as follows: Get the set of all running relays from onionoo (ignore non-running relays for the sake of convenience) For each relay (relay A) in the set, and for each relay (relay B) in relay A’s family, check to see whether relay A is included in relay B’s family. If not, there is no bidirectionality. The results (Number of running relays = 6774): Number of bidirectional pairs: 5911 Number of non-bidirectional pairs: 532 Number of pairs where either relay has not family list at all: 49 Sean From: tor-dev-request(a)lists.torproject.org Sent: ‎Wednesday‎, ‎June‎ ‎3‎, ‎2015 ‎9‎:‎00‎ ‎PM To: tor-dev(a)lists.torproject.org 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: onionoo: bug in family set detection? (teor) 2. Re: onionoo: bug in family set detection? (nusenu) 3. Re: onionoo: bug in family set detection? (l.m) 4. Researching Tor: Quantifying anonymity against a global passive adversary (Florian R?chel) ---------------------------------------------------------------------- Message: 1 Date: Wed, 3 Jun 2015 07:11:48 +1000 From: teor <teor2345(a)gmail.com> To: tor-dev(a)lists.torproject.org Subject: Re: [tor-dev] onionoo: bug in family set detection? Message-ID: <9BC4820F-A4E9-4168-BFCF-0E292524B4DB(a)gmail.com> Content-Type: text/plain; charset="us-ascii" Date: Tue, 02 Jun 2015 16:52:00 +0000 From: nusenu <nusenu(a)openmailbox.org> > > teor: > > MyFamily requires bidirectional declarations to be effective. > > I'm aware of that fact ;) > > > In this case: OnionOO appears to correctly implement the > > bidirectional MyFamily logic > > Apparently it doesn't. > > Since onionoo says there is a bidirectional "connection" (family) between > 5510FC1736B16D46D3F2DDA5011995C478D42594 => > 0C77421C890D16B6D201283A2244F43DF5BC89DD > > but there is none.. (as explained in my last email) > > Compass does *not* say that there is a bidirectional connection > between those relays.. onionoo says there is one even though I can't > see it, do you see it? I'm sorry, I must have got the onionoo and Compass results mixed up somehow. In Compass, I see that: 5510FC1736B16D46D3F2DDA5011995C478D42594 has no family. In Globe/Atlas (based on onionoo), I see that: 5510FC1736B16D46D3F2DDA5011995C478D42594 has a very large family. So my criticism of Compass actually applies to onionoo. 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 832 bytes Desc: Message signed with OpenPGP using GPGMail URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20150603/c42651ce…> ------------------------------ Message: 2 Date: Tue, 02 Jun 2015 21:58:52 +0000 From: nusenu <nusenu(a)openmailbox.org> To: tor-dev(a)lists.torproject.org Subject: Re: [tor-dev] onionoo: bug in family set detection? Message-ID: <556E271C.20501(a)openmailbox.org> Content-Type: text/plain; charset=windows-1252 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 https://trac.torproject.org/projects/tor/ticket/16276 -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJVbiccAAoJEFv7XvVCELh0/rUP/i7Q/cZwYaklkvHAaqmsDffK x8J77/21/5ppN1kyPd8jI7M8ktOC+1uqhV4mlf5CyidKR+2kAhhPYjfX57xQ1sbv OJwDq33EbQiTk/ed3DLQdQpbrt7fqaAzZi3+q2NIKMx2/GFRs6Sxnp7D9b69TEt3 WgW2sEuAuexl//HU01dKxPXp6+5EiW6UBz0eUJcTz4WUf/+CltRBg4sbBXImls3w J5mLqMNwyrRT/StTZB5oSMHsOfxQGgGGJppT0l91onQLzpM1A38ZtgN2zs5tD6T9 OSl7hwhUJHaWR3mg9vDywXO0CQ8tTadfZLGtDU0q5H88vU00jTRW1XA7bKLxtLqY INu9APIjnOhaatVTRGhJMMvP/Vuk6OE/L9n2FBw5FAPxmJ3Tn0+NwElamYizq7o8 AMNpWcfjHxAiH7R9PEuhwYyNktlBz3Swm4uNFvSGPaJsm99lxJLmd7ko9qrxd5Cm WcmQvPpfXN9Ym5iTWlMpu17MLmBGb2YgshFv+fTViCY1JwaEqAlTP+5/m2XmnM2x 8CZgNHjL1C7QWffx6AQYqcoAP183ClR3MD9poan7LMYfaqxXIbLceCzMOKeu9Ptt KPAdPAvACngB9kz43oQeJanE/nmjW90j/hr5oPezL57ayJEvpRiT+cmkkRTT2RvB Aj2Q3IqrXhOzTJkR+N94 =pTF3 -----END PGP SIGNATURE----- ------------------------------ Message: 3 Date: Tue, 02 Jun 2015 19:47:33 -0400 From: "l.m" <ter.one.leeboi(a)hush.com> To: tor-dev(a)lists.torproject.org Subject: Re: [tor-dev] onionoo: bug in family set detection? Message-ID: <20150602234733.2D552E04C1(a)smtp.hushmail.com> Content-Type: text/plain; charset="utf-8" Hello, DirAuth's can cache multiple versions of the descriptor and serve what appears to be the newest in a given consensus interval. This coupled with routers publishing descriptors at least every 18 hours, but potentially sooner. What you describe doesn't appear to be a bug in Onionoo because a consensus exists for which the family is declared as you describe in the last known good descriptor. At the moment you describe Atlas doesn't show: [1] last published 2015-06-02 17:44:27 (and [2] may still have entered hibernate) [2] last published 2015-06-02 09:40:45 (and [1] may not be running, or have a last known good descriptor at DirAuths) This doesn't take into account the possibility of a router hibernating (info not always available) at times between consensus taken or valid. A router can be running but unavailable due to accounting. This looks like a result of cached descriptors or router accounting. The data provided to Onionoo from metrics-lib appears accurate as far as network status. At least that's how it looks from a preliminary glance at the data and spec--although please do your own verification. --leeroy -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20150602/35e00c6f…> ------------------------------ Message: 4 Date: Wed, 03 Jun 2015 13:38:05 +0200 From: Florian R?chel <florian.ruechel.tor(a)inexplicity.de> To: tor-dev(a)lists.torproject.org Subject: [tor-dev] Researching Tor: Quantifying anonymity against a global passive adversary Message-ID: <556EE71D.5030507(a)inexplicity.de> Content-Type: text/plain; charset=utf-8 Hi there, I am currently writing my Master's thesis about Mix networks & Tor (was on list previously). I am currently at a point, where I'd like to practially quantify anonymity. That is, given a pcap, I want to anaylze how successful an adversary can determine whether a specific client talked to a specific service. Since I run all of this in a simulation (using Shadow), I have access to ground truth and can determine the traffic, network size, etc. arbitrarily. The idea behind all of this is to integrate a Mix relay on each Tor node and to watch how the adversarys success behaves. However, I have a hard time finding material on such attacks, i.e. papers that closely examine this scenario (and perhaps have conducted some simulation and/or measurements themselves, beyond simple theory). The thing is that this is only part of the research and I'd really prefer if I could build this upon work of others instead of starting from scratch. Do any of you know of such papers or corresponding research? Regards, Florian ------------------------------ Subject: Digest Footer _______________________________________________ tor-dev mailing list tor-dev(a)lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev ------------------------------ End of tor-dev Digest, Vol 53, Issue 6 **************************************

2 1

1st status report for OnioNS
by OnioNS Dev 04 Jun '15

04 Jun '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 For this first status update on my SoP project (the Onion Name System), I'd like to give a quick run-down of where the project currently is. I would consider OnioNS ahead of schedule as I made significant progress on it for the paper before the SoP program officially began. The following features are in place: *Client-side:* * A reliable Stem script that intercepts a .tor domain and sends it to the OnioNS client. It sets Tor to leave streams unattached, then auto-attaches non .tor streams, and rewrites .tor to .onion before attaching. Thank you arma! * Reliable IPC communication over a localhost TCP socket between the Stem script and the OnioNS client. The IPC syntax is simple enough to support telnet or other tools. * Ability to specify the IP of a name server (essentially a Mirror, but the name server isn't mirroring anything since the Synchronization protocol isn't there yet). * JSON communication over a Tor circuit (SOCKS username "OnioNS") to a name server. * The ability to verify the signature and proof-of-work of a Record. *HS-side:* * The capability to create and validate (through scrypt proof-of-work) a Record. * Prompts to allow a user to specify the domain name and subdomain-destinations that they want for their hidden service. * The printout in JSON of a Record, which one can copy and send over email or IRC until I get the upload protocols in place. *Server-side:* * JSON communication to make life easy. * TCP server for receiving a .tor domain and returning a Record. * Support for multiple Records. * The ability to accept and cache a new Record. * Construction of a Merkle tree and RSA-signing of the root. * Ability to find a Record in the Merkle tree, or to find a subtree that proves a domain's non-existence. *General:* * A hidden service for this project. * Reliance on Botan rather than OpenSSL. The difference is night and day. Thank you Yawning! * A Record for example.tor and several others for testing and illustrative purposes. * Clean and organized code. The style is similar to Chromium with the exception that I put three spaces between each method. I enforce the style with clang-format. * A basic but functional manpage. * Support for Clang and GCC, with Clang being the preferred compiler for development and GCC is used when packaging. * Packaging into a PPA on Launchpad for Ubuntu 14.04 and beyond, so "tor-onions" can be installed and updated through apt-get. I also support Debian 8+ but do not currently package for it. * Packaging for x86, amd64, and armhf, so I'm supporting Pis/BBB/Odroid as well. * Many labeled tickets on Github to improve workflow. * Signed git tagging. As you can imagine, this constitutes the bulk of the essential functionality. The remainder is primarily networking and server-side protocols, such as the Quorum, the Synchronization and Broadcast (upload) protocols, various algorithms, and so on. Those are next. I'm temporarily in a remote location and the Internet here is slow and quite spotty, so the project's hidden service is down and I haven't tested the latest commits over the network. However, once I have the Internet figured out I'll post a prototype here that everyone can test if they like. It's a centralized DNS at the moment, so spreading it out is next on the list. - - Jesse V. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCAAGBQJVcJMiAAoJEK2XNk/CC+yAPAAH/3uFvSXRwpq8QfE7o///Cc5a 5w3NwTP06pp1+AQ8RNUhmt17z3eHYOJJpP6zP4uwEzwAnNbUAs/8GiGdDOUj5Se3 kCUPh8/0s+yHWb02ctVhOYE32CouUVQHnswtuDRjz9KPO9Z3yG2d16TUINOurfKf tigUlgrRaW5pOIm0CQ2z4epi7FFKwdPjdTpsdbZURZTwybCiS4vgfN08iaIRZ/3M 9tz1tfQZH303yTQwubdYf9l99XJlxBtFBFjJlJzCze7iOEVD+j0fHRKk6OM/wouD kjKrarEQQACQhUzNssAr2/Yv/odYvshJYSLe/7/eoGH7zkKof0rbcBQPyLUpZoU= =B+Hz -----END PGP SIGNATURE-----

1 0

Deadline Approaching: The Global Technology Management Conference 2015 - USA
by Jackie Blanco 04 Jun '15

04 Jun '15

The Global Technology Management Conference (GTMC2015) Bemidji State University, Minnesota, USA July 15 - 17, 2015 http://sdiwc.net/conferences/gtmc2015/ [1] You are invited to participate in The Global Technology Management Conference (GTMC2015) that will be held at Bemidji State University, Minnesota, USA on July 15 - 17, 2015. The event will be held over three days, with presentations delivered by researchers from the international community, including presentations from keynote speakers and state-of-the-art lectures. The proceedings will be published in SDIWC Digital Library. The conference welcome papers on the following (but not limited to) research topics: *Information Technology -Information and Data Management -Information Content Security -The Management of IT Investments -Computational Intelligence -Data Management in Mobile Peer-to-Peer Networks -Information Management -Enterprise Architecture Management -The Management of "Green" IT -Ubiquitous Computing, Services and Applications -Web Services Security -Information Ethics -Quality of Service, Scalability and Performance -Information Security and Cryptography -Data Stream Processing in Mobile/Sensor Networks *Computer Science -Biometrics Technologies -Computer Forensics -Computer Security -Data Mining -Distributed and Parallel Applications -Wireless Communications -Cloud Computing -Access Control -Network Security -Digital Signal and Image Processing -Multimedia Computing -Computer Animation -Computer Architecture -Artificial Intelligence -Information Retrieval -Natural Language Processing *Business, and Technology In Education -Educational Technology -Computer-aided Systems -Mobile Computing -Education In Computational Science -Mobile Learning -Business Intelligence and Web Services -E-commerce Business Models -Future Development of E-Business -E- Learning -E-Government -Debugging Tools and Learning -E-Business Applications and Software *Manufacturing Systems -Design and Manufacturing -Intelligent Processing of Materials -Human-Machine Interface -Computer-Aided Design, Manufacturing, and Engineering -Modeling and Design -Design and Green Manufacturing -Automation -Networks Design, Protocols and Management *Engineering Technology -Bioinformatics & Biomedical Imaging -Robotics and Atomization Engineering -Globalization of Engineering -Applications of AI Techniques in Design and Manufacturing -Industrial Engineering -Biomedical Signal Processing -Robotics and Mobile Machines -Computer Architecture for Intelligent Machines All submitted papers will be reviewed by a minimum of two reviewers. The published proceedings will be indexed in ResearchBib, ProQuest, and Google Scholar Databases, in addition they will be submitted for POSSIBLE inclusion within the INSPEC, EI, DBLP, Microsoft Academic Research, and ResearchGate. IMPORTANT DATES =============== Submission Deadline: Open from now until June 15, 2015 Notification of Acceptance: 4 weeks from the submission date Camera Ready Submission: Open from now until July 05, 2015 Registration Deadline: Open from now until July 05, 2015 Conference Dates: July 15 - 17, 2015 Drop us an email at gtmc15(a)sdiwc.net Links: ------ [1] http://sdiwc.net/conferences/gtmc2015/

1 0

Dumb or-ctl-filter tricks (Was: [tor-talk] SOCKS proxy to sit between user and Tor?)
by Yawning Angel 04 Jun '15

04 Jun '15

Hello, I just pushed a fairly large update to or-ctl-filter, that lets you do lots of interesting things, most of them probably unsafe. In particular or-ctl-filter now ships with a SOCKS5 client/server implementation and a stub control port implementation. A picture is worth a thousand words: https://raw.github.com/Yawning/or-ctl-filter/screenshots/or-ctl-filter-tor-… What it does: * Filters the control port exposed to Tor Browser for things that (IMO) the browser has no business knowing just in terms of attack surface. In particular this intentionally breaks the circuit display feature as part of 4.5.x. * Allows easy integration of Tor Browser with a system tor service (NB: I run a system tor service with the Tor Browser circuit lifespan patch, if you do not, you will get behavior that is different from other users. You have been warned.) * Supports transparently redirecting ".i2p" requests to an I2P instance. Tor does not need to be running for this. * Enforces isolation to attempt to guard the local I2P web server and management interface from cross protocol trickery, evil Javascript and whatnot. * Supports running without Tor or I2P at all, essentially changing Tor Browser into Firefox with a bunch of patches. Limitations: * NEWNYM does not affect I2P tunnels. * "New Tor Circuit For This Site" does not affect I2P tunnels either. * Only cookie authentication is supported because I'm lazy, and it is the superior authentication method. * Launching Tor/I2P is not or-ctl-filter's problem and will never be part of the feature set. I have systemd for that. Warning(s): * Very alpha. It is entirely possible that I screwed up enforcing isolation. You can hard disable access to locally hosted i2p services like the management console in the config file. It is still probably 3 million times better than using privoxy/random sketch addons to do something like this because I actually do look at circuit isolation from Tor Browser and propagate it to Tor (or enforce it as best as I can otherwise). * If you enable logging, it will happily splatter destinations, authentication credentials, and everything else to the log, because it is a debugging feature, so don't. * If you enable the option named "UnsafeAllowDirect" and disable Tor, it will happily connect directly to the internet, destroying your anonymity. * Untested on Windows. Should work, don't care if it doesn't. Patches will sit in my INBOX forever; ignored, and unloved, just like the operating system they target. The same goes for OSX.[0] Code: https://github.com/Yawning/or-ctl-filter/tree/master -- Yawning Angel [0]: Honestly, I'll merge trivial things, but I won't bust out my windows box to test/debug this, and I don't have an OSX box.

2 1

Summary of meek's costs, May 2015
by David Fifield 04 Jun '15

04 Jun '15

Here's the summary of meek's CDN fees for May 2015. App Engine + Amazon + Azure = total by month February 2014 $0.09 + -- + -- = $0.09 March 2014 $0.00 + -- + -- = $0.00 April 2014 $0.73 + -- + -- = $0.73 May 2014 $0.69 + -- + -- = $0.69 June 2014 $0.65 + -- + -- = $0.65 July 2014 $0.56 + $0.00 + -- = $0.56 August 2014 $1.56 + $3.10 + -- = $4.66 September 2014 $4.02 + $4.59 + $0.00 = $8.61 October 2014 $40.85 + $130.29 + $0.00 = $171.14 November 2014 $224.67 + $362.60 + $0.00 = $587.27 December 2014 $326.81 + $417.31 + $0.00 = $744.12 January 2015 $464.37 + $669.02 + $0.00 = $1133.39 February 2015 $650.53 + $604.83 + $0.00 = $1255.36 March 2015 $690.29 + $815.68 + $0.00 = $1505.97 April 2015 $886.43 + $785.37 + $0.00 = $1671.80 May 2015 $871.64 + $896.39 + $0.00 = $1768.03 -- total by CDN $4163.89 + $4689.18 + $0.00 = $8853.07 grand total The number of users stayed in the range of 3000 to 4000. There are a few days of missing data. I think the big increase to 6000+ users on the day before the gap is a bad measurement. https://metrics.torproject.org/userstats-bridge-transport.html?graph=userst… On May 22 I asked the operator of the meek-google bridge to rate-limit the bridge to 1.5 MB/s in an attempt to limit costs. Since then we further limited it to 1.1 MB/s. It pains me to do that, but I need to find a way to make the operation of this transport sustainable. I estimated the rates to keep us under the $500/month credit we have from Google. I may also rate-limit meek-amazon too. If you want to set up your own bridge and CDN instance without rate limiting, I can help you do that if you email me. Here are some docs to look at: https://trac.torproject.org/projects/tor/wiki/doc/meek#Howtorunameek-server… https://trac.torproject.org/projects/tor/wiki/doc/meek#GoogleAppEngine https://trac.torproject.org/projects/tor/wiki/doc/meek#AmazonCloudFront https://trac.torproject.org/projects/tor/wiki/doc/meek#MicrosoftAzure == App Engine a.k.a. meek-google == Total bandwidth was down, probably because of the new rate limiting. Oddly, instance hours were way up, perhaps for the same reason. The rate limiting happens at the bridge, so it's possible that it's wasting resources at the App Engine level. Here is how the Google costs broke down: 5359 GB $643.07 4571 instance hours $228.57 Compared to the previous month: 6304 GB $756.59 2597 instance hours $129.84 In the graph you can really see the impact of limiting bandwidth. Interestingly, the number of users did not decrease. It's just going slower for them :( https://globe.torproject.org/#/bridge/88F745840F47CE0C6A4FE61D827950B06F9E4… == Amazon a.k.a. meek-amazon == Requests were up about 13% and bandwidth was up about 15%. Asia Pacific (Singapore) 132M requests $158.86 973 GB $129.18 Asia Pacific (Sydney) 633K requests $0.79 4 GB $0.58 Asia Pacific (Tokyo) 47M requests $57.04 331 GB $43.14 EU (Ireland) 184M requests $221.61 1847 GB $147.56 South America (Sao Paulo) 7M requests $17.04 49 GB $11.73 US East (Northern Virginia) 68M requests $68.57 509 GB $40.27 -- total 441M requests $523.91 3715 GB $372.46 https://globe.torproject.org/#/bridge/3FD131B74D9A96190B1EE5D31E91757FADA1A… == Azure a.k.a. meek-azure == meek-azure increased about 30% again this month. You should only count on it working for another 3 months. https://onionoo.torproject.org/bandwidth?fingerprint=AA033EEB61601B2B7312D8… Estimated bandwidth use this month: 2015-05 2592 GB Compared to last month: 2015-04 1982 GB https://globe.torproject.org/#/bridge/AA033EEB61601B2B7312D89B62AAA23DC3ED8… David Fifield Earlier reports in this series: https://lists.torproject.org/pipermail/tor-dev/2014-August/007429.html https://lists.torproject.org/pipermail/tor-dev/2014-October/007576.html https://lists.torproject.org/pipermail/tor-dev/2014-November/007716.html https://lists.torproject.org/pipermail/tor-dev/2014-December/007916.html https://lists.torproject.org/pipermail/tor-dev/2015-January/008082.html https://lists.torproject.org/pipermail/tor-dev/2015-February/008235.html https://lists.torproject.org/pipermail/tor-dev/2015-March/008427.html https://lists.torproject.org/pipermail/tor-dev/2015-April/008596.html https://lists.torproject.org/pipermail/tor-dev/2015-May/008767.html

1 0

Researching Tor: Quantifying anonymity against a global passive adversary
by Florian Rüchel 03 Jun '15

03 Jun '15

Hi there, I am currently writing my Master's thesis about Mix networks & Tor (was on list previously). I am currently at a point, where I'd like to practially quantify anonymity. That is, given a pcap, I want to anaylze how successful an adversary can determine whether a specific client talked to a specific service. Since I run all of this in a simulation (using Shadow), I have access to ground truth and can determine the traffic, network size, etc. arbitrarily. The idea behind all of this is to integrate a Mix relay on each Tor node and to watch how the adversarys success behaves. However, I have a hard time finding material on such attacks, i.e. papers that closely examine this scenario (and perhaps have conducted some simulation and/or measurements themselves, beyond simple theory). The thing is that this is only part of the research and I'd really prefer if I could build this upon work of others instead of starting from scratch. Do any of you know of such papers or corresponding research? Regards, Florian

3 2

onionoo: bug in family set detection?
by nusenu 02 Jun '15

02 Jun '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi, by comparing different methodologies of "parsing" myfamily data I stumbled upon differences between onionoo and compass. After manual review I assume there is a bug in onionoo (or onionoo has a different opinion on what families actually are) Example: According to onionoo, torpidsDEevanzo [1] is part of a family with 38 members. It lists torpidsFRonline [2] as one of its members, that implies that torpidsFRonline lists torpidsDEevanzo as one of its members as well, but torpidsDEevanzo does _not_ list torpidsFRonline (according to onionoo data). grep 'fingerprint":"0C77421C890D16B6D201283A2' details.json|grep 5510FC1736B16D46D3F2DDA5011995C478D42594 (no result) Is this a bug? thanks [1] https://atlas.torproject.org/#details/5510FC1736B16D46D3F2DDA5011995C478D42… [2] https://atlas.torproject.org/#details/0C77421C890D16B6D201283A2244F43DF5BC8… -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJVbLCAAAoJEFv7XvVCELh0bxkP/1Ep/fhLMhHGIgYnVzEj+xyJ Sb4gqUBuwLckcXLAYGoKZkIeHNS4TFLBidKxuP54bvSLgqPgpsy+OzLiaUk8AYyP Ea2tTmDqcjWy2v/cpP43M3Vh+TpPBTMenNajKwe9Moz63pMpo0V9HLnBjCwBN+Mh 1vGFJw/ov4wmQO3J5OOEABdVt8RTmqCWJBVbz1NmKWNEpxa5sbPS+6tNEvBLbsaL XmtoPcdyAl+14QQk1GSq4Px49K4MFEcRuCN2r1bzRv2WaPgRmFUtrK9JCDwwLlV5 aSrBU7S2M5gn6KowkEZllniZ7n5Ze3SiifqJEPm3hyIUXczveR02LHk++lEXneQE pqxDX6PPnVIt7lm1JW5Svr82boYTC1LQ9xHyF9LStBfYvgWSD5TrDeNaIe8+mka3 OrJ6r0hxMB1IRUaxouI/IGMZLmwj2lqifBeaNccsz876oJ2W6SZu6JPVvNstf7lc TnesBplpAprekofUb3DaGeM80Pa/NmuRjga5F+H6HLH3qE8AxeGKzSQDKYLuRlaM GdZY/bMN/6JGhoHCvYIT8NMNGMYfMPE7UWiHtX+1dezIwyYtwnHxiAcRl/e73TuI cmtzvIiKA9Z1sM2FX8mhaRi6r6TOBdvovSTkKtxkXHk2qT1Sf/oPtvlGtzTlrVp7 uFFgl0Sg++eiHAd1VG58 =D6Qh -----END PGP SIGNATURE-----

2 2

Re: [tor-dev] onionoo: bug in family set detection?
by teor 02 Jun '15

02 Jun '15

Date: Tue, 02 Jun 2015 16:52:00 +0000 From: nusenu <nusenu(a)openmailbox.org> > > teor: > > MyFamily requires bidirectional declarations to be effective. > > I'm aware of that fact ;) > > > In this case: OnionOO appears to correctly implement the > > bidirectional MyFamily logic > > Apparently it doesn't. > > Since onionoo says there is a bidirectional "connection" (family) between > 5510FC1736B16D46D3F2DDA5011995C478D42594 => > 0C77421C890D16B6D201283A2244F43DF5BC89DD > > but there is none.. (as explained in my last email) > > Compass does *not* say that there is a bidirectional connection > between those relays.. onionoo says there is one even though I can't > see it, do you see it? I'm sorry, I must have got the onionoo and Compass results mixed up somehow. In Compass, I see that: 5510FC1736B16D46D3F2DDA5011995C478D42594 has no family. In Globe/Atlas (based on onionoo), I see that: 5510FC1736B16D46D3F2DDA5011995C478D42594 has a very large family. So my criticism of Compass actually applies to onionoo. 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

OS X OpenSSL/Tor Build Instructions
by teor 02 Jun '15

02 Jun '15

As noted recently, OS X comes with OpenSSL 0.9.8 by default, which is too old to build Tor. During the Tor patch workshop today, rl1987 and Yawning were testing the OpenSSL and Tor builds on OS X. I've put the OS X build steps they used on the Tor Wiki, along with the alternative method of obtaining OpenSSL and/or Tor via MacPorts: https://trac.torproject.org/projects/tor/wiki/doc/MacBuild If you're building Tor on OS X, please try these instructions, fix any mistakes, and add missing steps or other alternatives. In particular, HomeBrew instructions for OpenSSL and Tor would be really helpful for some users. 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] The Onion Name System (OnioNS)
by OnioNS Dev 02 Jun '15

02 Jun '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 > What's to stop a sybil attack where the malicious relays try to occupy likely site(s) for the next Quorum? > > Is the consensus unpredictable enough to thwart this attack? > Even during quiet times? (Does Tor have quiet times?) As you can see from the ACM paper, I estimated 16Kb - 28Kb from routers leaving/joining the consensus, and my Markov Model analysis shows ~9000 bits from routers changing in some degree or another. Certainly the size and dynamics of the Tor network are enough to put the entropy above 256 bits, so I'm confident that any sort of malicious maneuvers (such as changing router descriptors so that the SHA-384 hash results in an attacker-pleasing Quorum) is hard because of the cryptographic defenses of SHA-384 and because the consensus has a large degree of entropy. I believe (but cannot prove) that those numbers are a lower-bound, though formally it's just an estimation. Sybil attacks are possible but expensive. They would have to gain the Fast and Stable flags and be subtle enough to not be detected by the Tor community (the Lizard Squad learned that the hard way). Sybil attacks would also likely compromise Tor and hidden services, which is outside my security assumptions. > Can we ensure the Quorum servers have to be long-lived and high-capacity (for example, guards) to make it harder to spin up servers and immediately be added to the Quorum? > I'm not convinced the Stable flag is hard enough to get. Of course, there's a trade-off where making the set of Quorum Candidates too small makes the Quorum easier to predict, too. One possible counter-measure is the Sybil attack detector that was posted here the other day. It might be a good idea, I'll think more about that. > By the way, in your ACM paper 5.4.2 you switch from Charlie to Alice, but I think they're meant to be the same Quorum Candidate. Thanks, I'll take another look. Alice is always a Tor client. > The HS is down, and has been for some days. Yes. I'm currently hosting it myself and I'm currently but temporarily in a remote location where the Internet is spotty at best. By the time I deploy OnioNS into beta or into production I'll have a stable host for the HS. I'll have it up soon. In the meantime, you can always clone and browse the Github repo that powers it, OnioNS-www. > I have two questions about the Stem-based approach: > 1. Applications which use Tor via SOCKS won't be able to use .tor domains without using Stem. This adds another dependency to apps which want to use .tor addresses, and confuses users by making .tor addresses work with some torified apps, and not others. Is your final goal to have .tor lookups contained within the Tor client? I'm sure someone could help with the C coding if that's the issue, particularly given a working implementation in Python/Stem. If a user wants to use a .tor address with something other than the Tor Browser, they will have to have both the Stem and the OnioNS client software running in the background. It should be application-independent. Eventually I would like the Stem code in the Tor client, and theoretically it should not be hard to do so. Currently I have a very reliable Stem solution (for which I am very thankful) and I will be utilizing that script for the time being. Based on a quick investigation it should also be easy to auto-launch it with the Tor Browser. I would like to see the OnioNS package in Linux or Tor repositories so that it may work as a general solution, and not something tied to the Tor Browser. > 2. I always feel nervous when people say "letting app X spin". I assume Tor Browser just looks like it's doing a DNS lookup or similar? I may have misused the term. It's not a busy-wait. Currently it's an idle synchronous wait on separate thread in the Stem script. The Tor Browser appears as if it's waiting for a DNS lookup to occur, which is essentially correct. Once that goes through, Tor attaches the stream to a .onion address, and the browser transitions to appearing as if it's waiting for a server over a high-latency connection, which is also correct. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCAAGBQJVbg1lAAoJEK2XNk/CC+yAnxEIAMn+XvrKX02+1OGrxQe4poNu hJzDcZHIJ5GTkYJk6iIOu7J+riz/f7rmQbvtxJWt3ZcAfebqcoec0j1kbvnFWDP4 /C35A4nSEN36XlDU/5AkYHv6l5dgvvxX+cDMSvHKFzrZU2m4uGAi5QF4qr3dqbbB ys6i1d4x/kuPvfFvZVrsiFVO0EKK5EzunccxHfly4aOpzksJlTCSrKSWoDwltpOK F9UKww53JTPbfNTMmqnOx9sE6DuPz3mNA7DMTMBiPjhl9nouq4mGFma60up2XY/u Ge9qOE7Wrrn95H9JZAR3uQqi5CehnAFd9h2fC2mcyAGkppJ69oOLhIBi/z94hC0= =Fygz -----END PGP SIGNATURE-----

1 0

T Shits for Relay Operators
by Abhiram Chintangal 02 Jun '15

02 Jun '15

Hello, Is the tshirt email system currently working? I have been running a relay since December and I haven't seen one. Btw, I did register my relay using tor weather. Thanks! -- Abhiram Chintangal

2 1

Re: [tor-dev] onionoo: bug in family set detection?
by teor 02 Jun '15

02 Jun '15

> Date: Mon, 01 Jun 2015 19:20:32 +0000 > From: nusenu <nusenu(a)openmailbox.org> > > Hi, > > by comparing different methodologies of "parsing" myfamily data I > stumbled upon differences between onionoo and compass. > > After manual review I assume there is a bug in onionoo (or onionoo has > a different opinion on what families actually are) > > Example: > > According to onionoo, torpidsDEevanzo [1] is part of a family with 38 > members. > > It lists torpidsFRonline [2] as one of its members, that implies that > torpidsFRonline lists torpidsDEevanzo as one of its members as well, > but torpidsDEevanzo does _not_ list torpidsFRonline (according to > onionoo data). > > grep 'fingerprint":"0C77421C890D16B6D201283A2' details.json|grep > 5510FC1736B16D46D3F2DDA5011995C478D42594 > (no result) > > Is this a bug? > > thanks > > [1] > https://atlas.torproject.org/#details/5510FC1736B16D46D3F2DDA5011995C478D42… > > [2] > https://atlas.torproject.org/#details/0C77421C890D16B6D201283A2244F43DF5BC8… No, it's a feature :-) MyFamily requires bidirectional declarations to be effective. This prevents a malicious relay nominating significant portions of the Tor network as its family, in order to direct traffic to another malicious relay. (And/or slowing down the network and attempting to cause a DoS.) In this case: torpids relays have inconsistent MyFamily configurations. OnionOO appears to correctly implement the bidirectional MyFamily logic, and remove inconsistent one-way MyFamily declarations. Compass appears to believe each relay's MyFamily claims, without checking the other relay. This appears to be a fairly harmless bug in Compass, as Compass itself is not used for path selection. 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 1

Re: [tor-dev] The Onion Name System (OnioNS)
by teor 02 Jun '15

02 Jun '15

> Date: Mon, 18 May 2015 15:48:50 -0800 > From: OnioNS Dev <kernelcorn(a)riseup.net> > > ... > > I introduce several data structures, but the most important one is the Pagechain, a distributed structure of linked Pages. Pages contain Records, Records contain .tor -> onion associations. Anyone who is familiar with blockchains will recognize the behavior and application of this structure immediately. However, here the head of the Pagechain is not managed by miners, but rather by a short-lived subset of Tor nodes called a Quorum. They receive Records and merge them into the Pagechain. At the moment I've decided to use 127 Quorum members and rotate them every week. They are randomly selected, but the process is deterministic; I am using the cached-certs + cached-microdesc-consensus documents, which everyone has, to seed a PRNG that then derives the Quorum. What's to stop a sybil attack where the malicious relays try to occupy likely site(s) for the next Quorum? Is the consensus unpredictable enough to thwart this attack? Even during quiet times? (Does Tor have quiet times?) Can we ensure the Quorum servers have to be long-lived and high-capacity (for example, guards) to make it harder to spin up servers and immediately be added to the Quorum? I'm not convinced the Stable flag is hard enough to get. Of course, there's a trade-off where making the set of Quorum Candidates too small makes the Quorum easier to predict, too. By the way, in your ACM paper 5.4.2 you switch from Charlie to Alice, but I think they're meant to be the same Quorum Candidate. > Clients don't need a copy of the Pagechain to use the DNS, but rather they can just rely on their existing trust of the Tor network (including the Quorum and name servers) and verify their signatures on data structures. > Also unlike a blockchain, my Pagechain has a finite length: the oldest Page will eventually drop off, which forces domains to be renewed periodically. I have also introduced mechanisms that 1) allows clients to authenticate the domain name to the hidden service, 2) allow clients to authenticate a denial-of-existence claim from a name server, and 3) prevent name servers from forging .tor -> .onion associations. These vulnerabilities are still generally open on the Internet DNS. I have also tried to minimize networking costs, since Tor circuits are slow. > > To reduce CPU and network requirements, I want Tor routers to have Ed25519 keys. Let this project add additional pressure on that item on the to-do list. > > Recommended readings: > http://onions55e7yam27n.onion -- the official hidden service for this project, but a work in progress. > https://github.com/Jesse-V/Thesis/blob/master/conference/acm-ccs.pdf -- the ACM paper pending peer review > I no longer recommending reading my original thesis, please use the above links instead. > The HS is down, and has been for some days. For those having trouble accessing the paper through the direct link, try clicking on acm-ccs.pdf on: https://github.com/Jesse-V/Thesis/tree/master/conference I got a format error from GitHub when I tried the direct link in Tor Browser 4.5. > … > > I am asking for help with the client-side functionality. I'm currently doing the *.tor interception and lookup resume in connection_edge.c but the software frequently crashes with this approach, (I've learned why) and I'd like to migrate it to Stem for now. I need to intercept .tor domains, pause the lookup (letting the Tor Browser spin), send the hostname over a named pipe or TCP socket, read back a .onion address, then tell Tor to resume the lookup under the .onion address. This way, the HS loads under a .tor domain. I have two questions about the Stem-based approach: 1. Applications which use Tor via SOCKS won't be able to use .tor domains without using Stem. This adds another dependency to apps which want to use .tor addresses, and confuses users by making .tor addresses work with some torified apps, and not others. Is your final goal to have .tor lookups contained within the Tor client? I'm sure someone could help with the C coding if that's the issue, particularly given a working implementation in Python/Stem. 2. I always feel nervous when people say "letting app X spin". I assume Tor Browser just looks like it's doing a DNS lookup or similar? 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 1