- tor-dev - lists.torproject.org

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