Opened 13 months ago

Last modified 9 months ago

#22728 new defect

Long-lived onion service circuits can enable guard discovery

Reported by: mikeperry Owned by:
Priority: Medium Milestone: Tor: unspecified
Component: Core Tor/Tor Version:
Severity: Normal Keywords: guard-discovery-stats, tor-hs
Cc: asn Actual Points:
Parent ID: Points:
Reviewer: Sponsor:


In Wilmington we brainstormed at least two different ways to perform guard discovery by keeping a circuit opened to a hidden service for a long time. These attacks will continue to work even after something like Proposal #247 is implemented.

Attack #1: Use many long-lived circuits to probe when the guard in use goes down. If several circuit teardowns are correlated with a guard going offline, you have a good candidate guard.

Attack #2: Keep a circuit opened long after a guard has been rotated away, and then start sending data down it. After one week, Tor decides that TLS connections are too old to use for new circuits, so after this point, your circuit should be one of the few things left on the TLS connection. Once this happens, if you can readily obtain netflow statistics at ISPs/core routers, you can walk your way all the way back to the client by seeing which Tor TLS connections match the byte counts you send.

We decided that this means we should close hidden service circuits after a day or so by default. Later, if we implement conflux, we could periodically reattach such circuits using conflux IDs instead.

We argued for a while about allowing people to have their Tor hidden service not kill long-lived circuits. I am of the opinion that we should allow this, with the appropriate warnings in the manpage and Tor log for the option.

Child Tickets

Change History (7)

comment:1 Changed 13 months ago by mikeperry

Keywords: tor-hs added

comment:2 Changed 13 months ago by arma

Is there any way to crank that "1 day" number up by a few days?

I expect people who e.g. ssh into their onion service will have their usability impacted by a daily hangup.

The first attack above is not resolved by hanging up on extra long lived circuits, since it just relies on having a bunch of circuits open, and "hours" is plenty.

Whereas the second attack above becomes a big deal because of the weekly rotation to a new tls connection, and because of the (monthly-ish, except it's more complicated because churn) rotation across guards. If we picked 1 day (for hangup) because we picked 7 days (for tls rotation), maybe we should crank up both?

comment:3 Changed 13 months ago by dgoulet

Milestone: Tor: unspecified

comment:4 Changed 9 months ago by mikeperry

Summary: Periodically close long-lived onion service circuitsLong-lived onion service circuits can enable guard discovery

Ok, I agree. It seems like simply closing circuits is not going to buy us much here.

How about providing the ability for clients to migrate circuits to an IP/RP? That way, if a client *should* rotate away from a node, it can. Additionally, if a node goes down because of DoS or any byzantine reason, this would mean that the circuit doesn't have to be destroyed. Basically, we could do conflux ( without the split-flow control stuff (at least not at first, though I suspect that the flow control pieces will be useful against congestion attacks).

comment:5 Changed 9 months ago by mikeperry

After thinking about the timeframes involved for attack 1 vs attack 2, I think that we should consider defending against attack 2 separately, again as a torrc option.

Attack 1 relies on an additional full-out DoS or an OOM killer side channel to do better than the guard downtime frequency, which should be months. Attack 2 just has to wait MAX(1 week, guard_layer_rotation_period). For middle nodes under prop247, guard_layer_roation_period is days/weeks.

Attack 1 makes me want to do conflux as per my previous comment, but because of the time duration and/or secondary attacks involved, attack 1 is actually lower severity than attack 2, and we still should provide an option for some hidden services to lower circuit lifetime because of this. I've filed #23980 for this. This ticket can be the place for deciding for what we want to about attack 1.

(TLS lifespan is orthogonal to both attacks, though. If services can reduce their circuit lifespan to minutes-hours, then 7 days of TLS lifespan is no longer a guard discovery vector. I would like to jack up TLS connection duration for other reasons, though. The TLS handshake has historically been a nightmare. We've wisely avoided these bugs by reducing our usage of its features. We should minimize its frequency of use, too. Why not?)

comment:6 Changed 9 months ago by mikeperry

Keywords: guard-discovery-stats added; guard-discovery removed

comment:7 Changed 9 months ago by asn

Cc: asn added
Note: See TracTickets for help on using tickets.