On 05/12/17 22:18, teor wrote: > >> On 6 Dec 2017, at 05:12, Michael Rogers <michael@xxxxxxxxxxxxxxxx> wrote: >> >> If the service needs to fetch a consensus and microdescs before it can >> respond to a rendezvous cell, the delay could be far longer than the >> difference in latency between a mobile phone and a laptop. So my point >> is that the client will be able to tell that the service was woken from >> idle by the rendezvous cell, which might have implications for the >> service's anonymity. >> >> For example, it lets the client know that the service isn't running on >> the same device as another service the client recently connected to, >> otherwise the device wouldn't have been idle. Maybe that's unavoidable, >> or not worth avoiding, but I just wanted to flag the issue. > > We try to avoid attacks like this. > Or, if we can't, we try to minimise their effect. > > But when multiple onion services or clients share a tor instance, they also > share the state of the consensus, directory documents, and guards. > > Our best answer is probably: "don't share a tor instance if you want > unlinkable onion services". > > Or: "don't IDLE if you want unlinkable onion services". > (Also, never lose your network connection.) Sounds reasonable. Maybe something to this effect could be added to the proposal, so app developers know what to expect in terms of linkability? Could a long delay between receiving a rendezvous cell and responding cause any other issues? For example, is there a high probability of the client timing out before the service has fetched enough directory info to be able to respond? If so, maybe it's worthwhile for the service to be more proactive about keeping its directory info fresh? >> Maybe I've misunderstood the proposal, but I thought the intent was that >> Tor wouldn't fetch anything in IDLE mode, and wouldn't automatically >> change from IDLE to IDLE_UPDATING - it would need a SLEEPWALK signal to >> tell it to change to IDLE_UPDATING, and then it would automatically >> change back to IDLE when it was done. > > LIVE fetches directory documents so it always has a live consensus. > IDLE fetches directory documents just often enough to stay online. > SLEEP fetches nothing. OK, so I guess the use case for SLEEPWALK is telling Tor to fetch a live consensus and microdescs when it otherwise wouldn't have done - i.e. it allows the controller to manage the freshness of the directory info? But I'm really just guessing here. Nick, can you clarify? >> Rather than the controller picking an interval, would it be better for >> Tor to specify (maybe in its response to the IDLE signal) when it next >> needs to be woken? > > Or, "the latest time it can be woken to have directory documents with > property X", where X is some combination of: > * a live consensus > * a reasonably live consensus > * enough non-expired descriptors to build circuits Yup, I think that makes sense - it achieves [what I guess is] the purpose of SLEEPWALK while keeping knowledge about *why* Tor needs to be woken at that time encapsulated within Tor, which is an improvement. >>> So if IDLE doesn't meet your needs, it would help us to know why. If >>> there's enough demand for it, it may be better to add a "WARM" state, >>> where Tor checks for directory documents whenever a consensus >>> expires, and otherwise acts like IDLE. >> >> Within the scope of this proposal that sounds like a good solution. But >> if we're looking ahead to changes that allow the device to sleep without >> shutting down Tor or disabling its network connectivity, then the >> controller will need to be responsible for managing sleeps and wakeups, >> which fits better with [my guess as to the intent of] the SLEEPWALK >> mechanism than a WARM state. > > We do need a use case here :-) > > And yes, I agree that the controller should be able to manage wakeups. OK, I have two use cases. They go beyond the scope of this proposal because they're also concerned with CPU wakeups, but I'm not sure we can really design the controller API without considering CPU wakeups at all. The first use case is saving power by putting the device to sleep, while keeping a hidden service available. "Sleep" on Android is similar to suspend on Linux (for recent Android kernels it's identical). User-space code is paused and the kernel only responds to a limited set of interrupts, including network activity and alarms. Entering this state without disabling Tor's network connectivity causes it to panic when the device wakes up - its libevent timers don't fire during sleep, so it thinks the clock has jumped. Just suppressing that panic reaction doesn't seem like a good idea. It would be better if we could warn Tor that the device is about to sleep, so it should stop building circuits and making connections, and should expect the clock to jump. This was my original motivation for asking for an "idle mode". If Tor tells the controller when it needs to be woken then the controller can schedule an alarm. The second use case is similar to the first, except the controller has less flexibility about scheduling alarms because the device is in "doze mode". This is a new power-saving mode on Android 6 that imposes extra restrictions beyond normal sleep, such as ignoring wake locks, shutting off network access and postponing alarms. If the user adds the app to a whitelist then it can hold wake locks and use the network, but it's still limited to scheduling alarms once every 15 minutes. (This is totally braindead, by the way - if you want to do one second of work every 14 minutes, your only choice is to hold a wake lock that keeps the device awake the whole time, whereas before the new "power saving" restrictions you could have scheduled an alarm and let the device sleep. But such is Android.) So for this use case, the controller can't wake Tor more than once every 15 minutes. If we're only waking Tor to fetch directory info and publish HS descriptors, that's probably fine. But other ideas we considered, like waking Tor once per minute so it can keep behaving more or less normally, won't work in doze mode. In both scenarios (sleep and doze), if there's any network activity before the next alarm, the controller can grab a wake lock to keep the device awake while Tor handles the network activity. There are two ways we could achieve that: Tor could inform the controller about the network activity, or Tor could connect to the network through a localhost proxy provided by the controller, which would manage the wake locks transparently. Cheers, Michael
Attachment:
0x9FC527CC.asc
Description: application/pgp-keys
Attachment:
signature.asc
Description: OpenPGP digital signature
_______________________________________________ tor-dev mailing list tor-dev@xxxxxxxxxxxxxxxxxxxx https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev