Re: [tor-bugs] #7066 [Tor]: Guard disablement by path-bias detector must be disabled or removed

["Tor Bug Tracker & Wiki" <torproject-admin@xxxxxxxxxxxxxx>]

#7066: Guard disablement by path-bias detector must be disabled or removed
------------------------+---------------------------------------------------
 Reporter:  rransom     |          Owner:                    
     Type:  defect      |         Status:  needs_revision    
 Priority:  blocker     |      Milestone:  Tor: 0.2.3.x-final
Component:  Tor         |        Version:                    
 Keywords:  tor-client  |         Parent:                    
   Points:              |   Actualpoints:                    
------------------------+---------------------------------------------------

Comment(by mikeperry):

 What warnings do you see again? There's a difference between the LD_BUG
 lines saying "This is a place where we might have miscounted/Tor circuit
 creation did something strange", and the "Your guard failed too many
 circuits" warnings...

 Also, for the record, in every case where we've seen these overcounting
 messages, I've immediately dropped everything to diagnose them and at
 least write code to ensure they did not impact results. In fact, to my
 knowledge, due to the path_state_t state transition checks, none of the
 LD_BUG lines actually indicate overcounting/undercounting anymore. They
 merely mean we detected a weird state transition where we *would* have
 miscounted, had we not performed the state check.

 Finally, I don't get how the guard rotation issue is comparable to the
 path bias attack. Tariq's paper calls your client's Guard list
 "compromised" as soon as you get one malicious Guard. I'm having a hard
 time seeing what attacks a malicious guard could perform that are more
 severe than this route capture attack...


 The path bias defense isn't perfect, but what it *does* do is impede
 deployment of a Tor-busting router module by real world adversaries (ie
 Cisco and Bluecoat) that can fully deanonymize Tor for targeted users. The
 device works like this: You turn on a module in your Cisco router/Bluecoat
 filter/whatever that blocks specific users' access to all Tor
 guards/bridges except those that you control/compromise/issue NSLs to get
 the keys for. You load those Guard keys onto the device, which is able to
 tag all Tor circuits to those guards so that they automatically fail,
 unless they also extend to exits (or hidden service end points) whose keys
 are also under you control.

 I'm not saying this warrants turning on the guard dropping defense in
 0.2.3.x. What I believe it *does* warrant is getting it deployed as soon
 as possible so that such Tor-busting router modules do *not* get created.
 I think this means using the log lines in 0.2.3.x to help us fine tune the
 defense for 0.2.4.x (and perhaps decide if it is worth upgrading the bw
 auths to measure ambient circuit failure if it is found to vary
 considerably). Otherwise, we won't have anything deployed for regular
 users at least until 0.2.5.x is stable, and by then, such Tor-busting
 router modules surely will exist (if they don't already).

 Obviously, the real solution to this mess is upgrading our protocols to
 remove malleability. However, I'm not optimistic we're going to have any
 clear notion on how to proceed on that front for several major Tor
 releases, and then there's the issue of waiting for whole the network to
 upgrade (including malicious Guards), while also avoiding any downgrade
 attacks. Unfortunately, I'm a shitty cryptographer, so instead of working
 on that front, I opted to try to buy us time to get that work+transition
 completed...

-- 
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/7066#comment:8>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs