- tor-dev - lists.torproject.org

small patch to allow gcc -fno-common for better ASAN coverage
by starlight.2015q2＠binnacle.cx 23 Jun '15

23 Jun '15

Per https://code.google.com/p/address-sanitizer/wiki/Flags one benefits from compiling with -fno-common when -fsanitize=address is active The attached patch converts the single common variable to a global/extern variable. Seems a good idea to me. Have run this with no issues, but more ASAN coverage is better than less.

1 0

How bad is not having 'enable-ec_nistp_64_gcc_128' really? (OpenBSD)
by nusenu 23 Jun '15

23 Jun '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi, since enable-ec_nistp_64_gcc_128 is disabled by default on OpenBSD due to compiler bugs [1] I wanted to ask how bad is it (in relay context) to ignore the usual tor log entry: > We were built to run on a 64-bit CPU, with OpenSSL 1.0.1 or later, > but with a version of OpenSSL that apparently lacks accelerated > support for the NIST P-224 and P-256 groups. Building openssl with > such support (using the enable-ec_nistp_64_gcc_128 option when > configuring it) would make ECDH much faster. Tor's changelog "highly recommends" it [2]. Can this be "translated" to something like "the relay's bandwidth usage and usefulness will be reduced" "latency will be higher" "security will be degraded due to fallback to DH-1024" ? thanks, nusenu [1] http://article.gmane.org/gmane.os.openbsd.misc/218944 [2] https://gitweb.torproject.org/tor.git/plain/ReleaseNotes?id=tor-0.2.5.10 -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJViDmDAAoJEFv7XvVCELh0Fi0QAKF0/7eVWgL5gExyGcCugz66 9CJOaNGVdeqb8LDxH/KEW4xC+MLhqMQ/+dL7iVOZIOtCM6i4vTpD3u4ZVnFhcGfx luyX78TqXDW3riV3izBWYScYxQdeHGv3XFXQlbGi7WQYfRt0AdorchmP2xuxD7Cg zGZFk4Bggj3qnW1sd/G3JvJL0bUi7iBKrQwPTDlnK3YSGbTYpU6lS3dQqbHqNYin yrwtlNSCi9DFjbQm5g4yjvaawnmOuxf8dlm54Ltjdn2cIHsXaPqQ6kXICiukrJhE ZLfTnPBd3yngyoq9xe7bW9P4mNVkTNmAU3VqGgEq1gSUJQObXkzOKAz63z9WAqQl GBvZFtwkbdBM4pjfWaG5FjDRc+awXxP/8K/d2vF2r6KAwkbh9Fw2uhjC6yu5c6hB KtQaovd+we+Ag4vDdE6lbQPLiCbPBiFdB6qYjkWbVflYcrsYQPoCgwjaodbV7I/Y 8Kb3Lx2C8+HFLtktEh19tOk34iKVliQk7FjE2FoiKkWryRYtY5KUAfFS8hOCfBqr 2XYtWGqQ9eh14RqvBu7CuN1cKCc0EQLcr6BF9uvd6EYtKZsa5rQC+y9Bbbd65MwB qU7lLckEkG+qwzgvuyOBvGwN8JmMmTBQASsdalAUscQFbPq7wySp9tz21pu8mOje NRRdnL1/3X9KcCMLMCVk =Oa2Z -----END PGP SIGNATURE-----

4 4

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

22 Jun '15

> Date: Thu, 18 Jun 2015 19:37:07 -0300 > From: ilv <ilv(a)riseup.net> > To: tor-dev(a)lists.torproject.org > > > … > >> 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 >> > > Yes, the use experience that you mention is what we're looking for. > About using the Tor network... I'm not sure about it. It's like using > Tor to download Tor? Still, I'll write it down as an option. People can use the Tor network to download Tor Browser, with the aid of a bootstrapping program. (Which can be much simpler than Tor Browser itself - see below.) If people can't use the Tor network to download a file, then it's unlikely that Tor Browser will work for them. My reasoning went something like this: 1. If we can put Tor Browser in an App Store, people won't need to use an app that downloads Tor Browser 2. If an App Store doesn't allow Tor Browser, then people need an app that will download Tor Browser 3. Perhaps the App Store will allow an app that can download Tor Browser over the Tor network (this could be as simple as tor, torify, and wget executables, and a GUI frontend) 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

The future of GetTor
by ilv 22 Jun '15

22 Jun '15

Hi people, I'm currently the maintainer of GetTor [1], and together with Nima and Sukhbir we have been talking about the future of it. First, let me present you what is (roughly) the current status of GetTor: * We send links to download Tor Browser, along with its signature file. These files are stored on Dropbox. I will be working on integrate new cloud/hosting services during Summer of Privacy. * We send these links via email. I will be working on new modules to send links via chat (XMPP) and Twitter (DM) during Summer of Privacy. * We send links to download the English (US) package of Tor Browser. I will be working on support for more locales during Summer of Privacy. That is what we have now. Is not much, but it works (more info in [1]). So, what about it? Software evolves, and we think it might be the time of GetTor to go beyond its current design. Moreover, we have received valid concerns that emails could be tampered and users could get malicious versions of Tor Browser (although we have no evidence that this is happening). Right now, when you get the Tor Browser via this method is up to you to verify its integrity. 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? 2) In case we develop the distributor, should the email autoresponder remain? 3) If you agree on developing the distributor, what option you think would fit better? (please suggest better options) I would really love to hear your comments about this idea, my work at Summer of Privacy might change depending on this discussion, so please feel free to express your feelings about it :) Thanks for your time! [1] https://www.torproject.org/projects/gettor.html.en [2] https://trac.torproject.org/projects/tor/wiki/org/roadmaps/GetTor --ilv

4 6

draft-grothoff-iesg-special-use-p2p-exit-00.xml
by Christian Grothoff 22 Jun '15

22 Jun '15

Dear all, Following https://datatracker.ietf.org/doc/draft-grothoff-iesg-special-use-p2p-names/ and the separation of .onion in https://tools.ietf.org/html/draft-appelbaum-dnsop-onion-tld-01 to satisfy the IETF's desire to have lots of documents, I've now split off ".exit" as well to create draft-grothoff-iesg-special-use-p2p-exit-00 I've attached the current draft to this e-mail and would appreciate any feedback you may have. Also, if you feel that this is the wrong move entirely (i.e. because you don't want to reserve .exit), please do let me know ASAP and then I won't submit the draft. Happy hacking! Christian

1 0

2nd status report for OnioNS
by OnioNS Dev 21 Jun '15

21 Jun '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hello everyone, Work on the Onion Name System (OnioNS) continues. As stated in the previous status report, my primary focus now is separating the server components. In the last release, a single name server handled everything, making it a centralized system. I have made significant progress in seperating roles such that one machine acts as an authority while another machine returns Records and digital signatures to clients. This reduces the loads and responsibilities and is the key step towards creating a true distributed system. During implementation, I decided the scrap the Snapshot data structure and its protocol. A Snapshot is basically a server-side short-term cache of Records that is then flushed out periodically. The issue is that in the event that two HSs claim the same name within a short time period of each other and transmit their Records to two different Quorum nodes, when the Snapshots are flushed out it's non-trivial to decide which one took precedence. Snapshots were originally intended to save networking costs and reduce the risk of timing attacks, but in the end I realized that it didn't actually reduce networking costs, and timing attacks are an acceptable risk given Tor's design and threat model. So instead, servers can now subscribe to other servers for network events. If server B is subscribed to server A, when a Record is transmitted from a HS through a Tor circuit to server A, it sends the Record to B immediately. Thus all Quorum nodes will subscribe to all other Quorum nodes, and Mirrors can subscribe to one or more Quorum nodes, and Mirrors can subscribe to other Mirrors. This allows new information to propagate across the network immediately. This simplifies some of the protocols and fixes a significant problem. I have also made significant progress on logging events to file, rather than to std::cout. I am also planning on loading networking information from a file, simulating a Quorum, maintaining a debug package, and launching the software with the Tor Browser. I have made progress on all of these and have listed them in a milestone, scheduled to be included in the next major release: https://github.com/Jesse-V/OnioNS/issues?q=is%3Aopen+is%3Aissue+milestone%3… See you at PETS! - - Jesse V. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCAAGBQJVhhTEAAoJEK2XNk/CC+yAIdMH/AlUiqCFsQCESe1I6tUzYfHO 4DLTZGVInSC1AMjhdO4RBLuO/MZuZgGAzsitI65KEOkYBAFd7TGOu8DMDbfU9tdt d9yRVshqP/LSd9b9/WmmVZTq0zazkZDOBYELcrXBw3ic4tu+HdJ5E3yl/Fm2bE5C eu0gVbBipvbj332cypqf6J2xpP5gQN5pdSLh+AHRqgMN1K9huTw/yq2/Kgu2ZmhX 8AoMerNmkQ9Wj+tUcyW+Ab9+SFUrkeYUxPp60WVXXciD311uUhKTKknGjRDgBNZw YSI/2RrHkW2342XfvaiI7qbgfnSKQx5yko9KxV2ab1JSpzgocgutWRjwSZFIt/M= =rqna -----END PGP SIGNATURE-----

1 0

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