Re: [tor-dev] Hidden Services and IP address changes

[George Kadianakis]

Martin Florian flor...@kit.edu writes:

 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...


Hello friend!

I opened a trac ticket for this whole hidden services on mobile
phones don't work that well issue. You can find it here:

  https://trac.torproject.org/projects/tor/ticket/16387

___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] The future of GetTor

[teor]

 
 Date: Mon, 15 Jun 2015 20:14:54 -0300
 From: ilv i...@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



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] The future of GetTor

[intrigeri]

Hi,

ilv wrote (15 Jun 2015 23:14:54 GMT) :
 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.

You might be interested in the work that's happening there:
https://tails.boum.org/blueprint/bootstrapping/extension/

(I'm not directly involved in this, for more information ask
sajol...@pimienta.org.)

Cheers,
--
intrigeri
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev