[tor-dev] Traffic correlation attacks on Hidden Services

[Paul Syverson]

Hi Virgil,

On Thu, Dec 24, 2015 at 06:08:51AM +0000, Virgil Griffith wrote:
> I've been looking into simple graph-theoretic metrics for Roster to
> quantifying Tor's susceptibility to traffic correlation attacks, mostly
> using BGPStream, https://bgpstream.caida.org/ .
> 
> All of the academic literature I've read talks about the risk to Tor users
> of an AS being in the path between client <-> guard + exit <-> destination.
> 
> Questions:
> (1) To ensure I'm not measuring the wrong thing, can someone be more
> specific on the correlation attack scenario for Tor hidden services?
> 
> (2) Just guessing, but would be it be the same but replace "exit <->
> destination" with: "HS server <-> HS guard" ?

To a first approximation, yes.

> 
> (3) If yes to (2), the natural solution is simply to install a Tor relay on
> the HS server itself so that there's no ASpath between the two?

A. This is a solution for a limited type of onion service providers.
People who are not in a position to have an IP-identified server on
the Tor network couldn't do this. People wanting to set up an
onion service where they can only make outbound connections couldn't
do this. People running ricochet or onionshare couldn't do this, etc.

B. Ignoring A: There is still an AS path between the onion service
server/relay and all the other relays. It is true that this hides
the connecting to the Tor network activity of the service qua client
vs. being a relay (which I think we first noted in "Towards an
Analysis of Onion Routing Security", though that was pre-Tor).
But if this were the common practice, then listing all the onion
service IP addresses would become trivial: they're all at publicly
listed Tor relays. So someone looking for a hidden service and owning
some ASes could do the correlations, except now they have a handy
and significant filter to look first for these at Tor relays.
Worse, since you are essentially doing away with guards
for onion services, anyone running a middle relay (easiest thing to
get in the network quickly) will be able to do the correlation you
were trying to prevent at the AS level. Our analysis of vulnerability
onion service connections to the network in just such a way was what
led to the introduction of guards in the first place (Cf. "Locating
Hidden Servers".) As with anything real, you gain some and lose
some in making such a change. But it seems that overall you lose
more.

> 
> Comments greatly appreciated.  I'm not an internet routing expert and I
> want to ensure Roster is incentivizing the right things to harden the
> network.
> 

HTH.

May the season make sense to you and yours,
Paul