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):
- (Setup) A hosts the HS X and A, B and C are all booted up.
- B connects to X - it works!
- A changes its IP address.
- B tries to talk to X again - doesn't work!
- 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
On 21/05/15 14:04, Nathan Freitas wrote:
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.
I think this may be a different problem from the one I looked at, which was related to introduction points rather than rendezvous points.
But that reminds me, the solution for the stale introduction point issue (flushing the HS descriptor from the cache on the client before connecting) still needs to go through the patch workshop. I'll bump that up the todo list.
The central issue that I discovered can be reproduced like this (assuming Tor clients A, B and C):
- (Setup) A hosts the HS X and A, B and C are all booted up.
- B connects to X - it works!
- A changes its IP address.
- B tries to talk to X again - doesn't work!
- 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 whether the RP knows that the service-RP circuit has died, and if so, should it tear down the client-RP circuit?
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?
It would be nice if we could find a way to detect this at the Tor level so we don't have to maintain two circuits between A and B.
Cheers, Michael
I'm ashamed to say in our case that we really just used the TOR HS as a proof of concept and never ran it long enough to run into all of these issues. We did run into something along these lines when we were testing and our solution was to aggressively kill connections and retry. Not exactly brilliant. :(
-----Original Message----- From: Michael Rogers [mailto:michael@briarproject.org] Sent: Thursday, May 21, 2015 6:17 AM To: Nathan Freitas; tor-dev@lists.torproject.org Cc: Yaron Goland Subject: Re: [tor-dev] Hidden Services and IP address changes
On 21/05/15 14:04, Nathan Freitas wrote:
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.
I think this may be a different problem from the one I looked at, which was related to introduction points rather than rendezvous points.
But that reminds me, the solution for the stale introduction point issue (flushing the HS descriptor from the cache on the client before connecting) still needs to go through the patch workshop. I'll bump that up the todo list.
The central issue that I discovered can be reproduced like this (assuming Tor clients A, B and C):
- (Setup) A hosts the HS X and A, B and C are all booted up.
- B connects to X - it works!
- A changes its IP address.
- B tries to talk to X again - doesn't work!
- 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 whether the RP knows that the service-RP circuit has died, and if so, should it tear down the client-RP circuit?
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?
It would be nice if we could find a way to detect this at the Tor level so we don't have to maintain two circuits between A and B.
Cheers, Michael
-
Michael Rogers -
Nathan Freitas -
Yaron Goland