Opened 13 months ago

Last modified 6 months ago

#23289 new enhancement

Improving HS reachability for Orbot/Android users

Reported by: n8fr8 Owned by: n8fr8
Priority: High Milestone: Tor: unspecified
Component: Core Tor/Tor Version:
Severity: Normal Keywords: orbot, mobile, android, 034-triage-20180328, 034-removed-20180328
Cc: michael@…, goapunk@… Actual Points:
Parent ID: Points:
Reviewer: Sponsor: Sponsor8-can

Description

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.

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

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

Child Tickets

Change History (8)

comment:1 Changed 13 months ago by akwizgran

Cc: michael@… added

comment:2 Changed 13 months ago by nickm

Component: Applications/OrbotCore Tor/Tor
Milestone: Tor: 0.3.2.x-final
Priority: MediumHigh
Sponsor: Sponsor8-can
Summary: Improving HS reachability in Orbot/AndroidImproving HS reachability for Orbot/Android users

Unless you disagree, I'm going to pull this into the Tor component, as they are all Tor changes. I'd like us to start looking at this kind of stuff soon, and aim for merging in the 0.3.2 merge window, though 0.3.3 seems more likely.

comment:3 Changed 13 months ago by nickm

Milestone: Tor: 0.3.2.x-finalTor: 0.3.3.x-final

comment:4 Changed 13 months ago by goapunk

Cc: goapunk@… added

comment:5 Changed 8 months ago by nickm

Milestone: Tor: 0.3.3.x-finalTor: 0.3.4.x-final

comment:6 Changed 6 months ago by nickm

Keywords: 034-triage-20180328 added

comment:7 Changed 6 months ago by nickm

Keywords: 034-removed-20180328 added

Per our triage process, these tickets are pending removal from 0.3.4.

comment:8 Changed 6 months ago by nickm

Milestone: Tor: 0.3.4.x-finalTor: unspecified

These tickets, tagged with 034-removed-*, are no longer in-scope for 0.3.4. We can reconsider any of them, if time permits.

Note: See TracTickets for help on using tickets.