[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
[tor-bugs] #23289 [Applications/Orbot]: Improving HS reachability in Orbot/Android
#23289: Improving HS reachability in Orbot/Android
------------------------------------+------------------------------------
Reporter: n8fr8 | Owner: n8fr8
Type: enhancement | Status: new
Priority: Medium | Milestone:
Component: Applications/Orbot | Version:
Severity: Normal | Keywords: orbot, mobile, android
Actual Points: | Parent ID:
Points: | Reviewer:
Sponsor: |
------------------------------------+------------------------------------
Orbot received a pull request here: https://github.com/n8fr8/orbot/pull/83
with proposed modifications to improve reachability of an HS running on
the device. We asked Michael Rogers from the Briar Project to review this
proposal, since his team has done the most with HS on mobile. The PR
details and his comments are inline below.
While these improvements seem worthwhile from a usability perspective,
there are concerns about impact on anonymity, as always.
****
The issue at the moment is that while the device is sleeping for long
periods of time, it is possible for the HS to become unreachable as a
result of Tor detecting a clock jump of length greater than
`NUM_JUMPED_SECONDS_BEFORE_WARN` (100 seconds) upon waking up, which
then closes all circuits. Another issue is that if the device was woken
up by incoming network traffic, the device only stays awake for about a
second before going back to sleep, which isn't enough time for Tor to
rebuild the intro circuits, and thus the HS is no longer reachable until
Tor is able to rebuild the circuits.
I attempt to improve this situation in two ways:
1. Increase `NUM_JUMPED_SECONDS_BEFORE_WARN` from 100 seconds to 600
seconds to avoid triggering the clock-jumped-close-all-circuits code
every time the device wakes up from sleep.
2. Add a new command (`MARKCONNFORWAKELOCK`) and event (`WAKELOCK`) to
the control port to allow Tor to synchronously signal Orbot to hold wake
lock on behalf of Tor (since it isn't possible to hold a wake lock from
native code). A wake lock is acquired at the start of a event callback,
then released when libevent returns from its event loop when there are
no active events. This prevents the device from sleeping when Tor still
has work to do.
****
Comments from Michael@BriarProject:
Thanks for passing this on. I've also been looking into this problem
lately. Comments inline below.
On 11/08/17 12:00, Nathan of Guardian wrote:
1. Increase `NUM_JUMPED_SECONDS_BEFORE_WARN` from 100 seconds to 600
seconds to avoid triggering the clock-jumped-close-all-circuits code
every time the device wakes up from sleep.
Is there something that makes 600 seconds qualitatively better than 100
seconds, or is this just a workaround for short sleeps?
2. Add a new command (`MARKCONNFORWAKELOCK`) and event (`WAKELOCK`) to
the control port to allow Tor to synchronously signal Orbot to hold
wake
lock on behalf of Tor (since it isn't possible to hold a wake lock
from
native code). A wake lock is acquired at the start of a event
callback,
then released when libevent returns from its event loop when there are
no active events. This prevents the device from sleeping when Tor
still
has work to do.
I like the underlying idea here, but this way of implementing it seems
risky.
The problem is that Tor is driven by two kinds of events: incoming
network traffic and libevent timers. When the device is asleep, incoming
traffic will briefly wake it, so you can grab a wake lock until Tor
finishes its work. But if a libevent timer expires during sleep, the
device won't be woken. The timer will be handled next time the device
wakes for some other reason.
I think this is a potential risk to anonymity, because it will result in
externally visible behaviour, such as circuit teardowns, happening in
correlated bursts when the device wakes up. And those bursts can be
triggered by sending traffic to the device.
Tor expects timers to run at the scheduled time. That's why it panics
and tears everything down if the clock jumps by 100 seconds. Suppressing
that panic response seems like a bad idea. More generally, ignoring the
assumption behind the panic response seems like a bad idea.
What would be a better idea?
Briar holds a wake lock whenever Tor is connected to the network, but
that kills the battery, so we have to find another way.
If we could put Tor into some kind of "idle mode", where it would shut
down all circuit building and other timer-driven behaviour, then it
might be safe to let the device sleep until it was woken by incoming
traffic. We could ask the guard for keepalives, say once every five
minutes, to ensure that periodic tasks like fetching the consensus and
uploading HS descriptors would have a chance to run even if there was no
incoming traffic. But those tasks would still happen in bursts, so it
seems to me that there would still be a risk to anonymity.
We might be able to reduce the burstiness if Tor could tell the
controller the time of the next consensus fetch or descriptor upload,
and the controller could use an alarm to wake the device at that time,
regardless of network traffic. Doze mode adds some restrictions here -
whitelisted apps can set an alarm every nine minutes, which might be
enough. The alarm could also be used to check the time of the last
keepalive, to detect dead guard connections.
I think doing this right is going to require significant input from the
Tor devs, first of all to see what we can safely get away with in terms
of sleep, and then perhaps to implement an idle mode and supporting
controller commands if it looks like a good idea.
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/23289>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs