Florentin Rochet: > On 2018-03-20 04:57, Mike Perry wrote: > ><skip> > >Arguments for staying with just one guard: > > > >1. One guard means less observability. > > > >As Roger put it in the above blog post: "I think the analysis of the > >network-level adversary in Aaron's paper is the strongest argument for > >restricting the variety of Internet paths that traffic takes between the > >Tor client and the Tor network." > >http://freehaven.net/anonbib/#ccs2013-usersrouted > > >Furthermore, I believe that conflux will also be useful against traffic > >analysis and congestion attacks. Since the load balancing is dynamic and > >hard to predict by an external observer, traffic correlation and website > >traffic fingerprinting attacks will become harder, because the adversary > >can no longer be sure what percentage of the traffic they have seen > >(depending on their position and other potential concurrent activity). > >Similarly, it should also help dampen congestion attacks, since traffic > >will automatically shift away from a congested guard. > > I am really enthusiast about multipath, either at the Tor level or even at > the transport level: we discussed QUIC at the meeting, but MultipathQUIC > could also be a long-term option now that we discuss more than 1 entry > guard. > > However, I would argue that it does not really help against traffic > correlation. Our paper at pets18 exploits Tor's forward compatibility > feature to design silent cheap, almost instantaneous and perfect active > traffic confirmation that does not care about user traffic to succeed. > > See Section 5, > https://petsymposium.org/2018/files/papers/issue2/popets-2018-0011.pdf In this case, Tor's forward compatibility is a bug. The Tor protocol is now versioned at the feature layer, so Postel-style permissive forward compatibility is no longer required: https://gitweb.torproject.org/torspec.git/tree/proposals/264-subprotocol-versions.txt I have been bothered by the types of side channels you discuss in that paper for some time. They are tricky to remove, but not impossible. See https://trac.torproject.org/projects/tor/ticket/25574 and the child ticket and associated branch. Your paper also states that you got multiplier effects from various issues with Tor's protocol, which improved your results. If we remove these multiplier effects by fixing the protocol and behavior, then it seems to me that adaptive traffic routing will add further uncertainty to congestion-based attacks. > Maybe the real debate would be to discuss what's the major threat between > active/passive attackers, and what do we care about? The question is, why > should we care about hardening passive attacker's work when the active form > is always as easy? To your point: because I believe it is possible to make both active and passive attacker's jobs hard. I also believe that when we look deeply enough, we will find that improvements that make an active attacker's task harder will also improve things against many, if not all, classes of passive attacker. Roger made a related point that I want to inject here, so I remember to pick it up in the proposal: Roger said that we should consider active vs passive observers here. He contended that against passive observers, one guard is always better, and that we should not discount that benefit while considering an active attacker making circuits via a second guard. However, there are two main issues with calling the Tor-sometimes-uses-a-second-guard "attack" fully "active": 1. It is not always active. In day-to-day operation, clients will use a second guard whenever they pick an exit that is in the same family or /16 of their primary guard (this is because Tor rightly chooses exits first, to avoid leaking guard node choice via exit node choice). Clients will also do this when an onion service's IP, HSDIR, or RP is in the same /16 or family as their primary guard, or actually is that guard. In these cases, they will perform a request over a second guard, with no benefit from multiplexing it with other traffic. For clients unlucky enough to choose guards in popular /16s or in big families, they will be using secondary guards for unmultiplexed activity quite frequently. 2. The active observer and the passive observers here are independent actors. The passive observers can be logging connection activity simply due to the default configuration of their network routers. Active adversaries do not need their collusion in this attack to get the full benefit from being active -- they merely need to have the ability to ask passive observers for the logs they already have, independent of the attack. > For website fingerprinting, it does seem to be interesting if the attack > cannot link the two paths :) This is by far the easiest argument to make for both the switch to two guards, the switch to conflux, and for the addition of padding: we know from the research literature on website traffic fingerprinting that more multiplexing reduces attacker accuracy. Both conflux and always-on two guards increase overall multiplexing, and eliminate cases where lack of multiplexing bites us hard. However, the mere fact that this is true against website traffic fingerprinting suggests to me that increased multiplexing and traffic splitting is useful in other traffic analysis scenarios. -- Mike Perry
Attachment:
signature.asc
Description: Digital signature
_______________________________________________ tor-dev mailing list tor-dev@xxxxxxxxxxxxxxxxxxxx https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev