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