Opened 9 years ago

Last modified 3 years ago

#5456 new project

Defend against path bias and tagging attacks

Reported by: mikeperry Owned by:
Priority: High Milestone: Tor: unspecified
Component: Core Tor/Tor Version:
Severity: Normal Keywords: SponsorZ-large, needs-proposal, tor-client research-program
Cc: rransom, nickm, arma, mikeperry, isis, saint Actual Points:
Parent ID: Points:
Reviewer: Sponsor:


In, some dude who claims to be a raccoon proved that tagging attacks are an amplification attack that allow an adversary who has c/n of the network bandwidth to compromise of c/n of all circuits through the network.

The tagging attack he describes is actually a subset of path bias attacks we've known about for a long time. Tagging is just a particularly nasty one that also allows for a level of amplification that we previously were not aware of.

This ticket is to serve as the parent ticket for several things we can do to improve the situation and defend against tagging in specific or path bias in general.

Child Tickets

#3890closedtbb-teamApplications should start using optimistic dataApplications/Tor Browser
#5343closedRequire a threshold of exit nodes before believing we can build circuitsCore Tor/Tor
#5457newBw auths don't count circuit failures in descriptor modeCore Tor/sbws
#5458closedmikeperryClients should warn and disable guards responsible for excessive circuit failuresCore Tor/Tor
#5459closedaagbsnExit scanner should scan for Guard <-> Exit reachabilityCore Tor/Torflow
#5460closednickmWrite proposal(s) to implement improved relay/circuit crypto authenticationCore Tor/Tor
#5563closedBetter support for ephemeral relay identity keysCore Tor/Tor
#5956closedmikeperryThresholds of nodes to build circuits should be tunable and maybe consider weights tooCore Tor/Tor
#5968newImprove onion key and TLS managementCore Tor/Tor
#6135closedTune + tighten path bias parametersCore Tor/Tor
#7003newWipe relay key material from memory on common crash conditionsCore Tor/Tor
#7157closed"Low circuit success rate %u/%u for guard %s=%s."Core Tor/Tor
#7509newPublish and use circuit success rates in extrainfo descriptorsCore Tor/Tor
#7582closedDon't disable exits so harshly for unexpected END_REASON_EXITPOLICYCore Tor/Tor
#9001newSlow Guard Discovery of Hidden Services and ClientsCore Tor/Tor

Change History (22)

comment:1 Changed 8 years ago by nickm

Milestone: Sponsor Z: November 1, 2013

Assigning this to sponsor Z, since it needs a Tor milestone. I'd like to get fixes into 0.2.3.x, except for the stuff that requires heavy research, which should target 0.2.4.x.

comment:2 Changed 8 years ago by karsten

Keywords: SponsorZ added
Milestone: Sponsor Z: November 1, 2013

Switching from using milestones to keywords for sponsor deliverables. See #6365 for details.

comment:3 Changed 8 years ago by mikeperry

Keywords: SponsorZ-large added; SponsorZ removed

There's a lot of stuff here. Could also fund some Torflow work.

comment:4 Changed 8 years ago by nickm

Milestone: Tor: 0.2.4.x-final

comment:5 Changed 8 years ago by nickm

Keywords: needs-proposal added

comment:6 Changed 8 years ago by nickm

Keywords: tor-client added

comment:7 Changed 8 years ago by nickm

Component: Tor ClientTor

comment:8 Changed 8 years ago by nickm

Mike, how much of this needs to get deferred out of 0.2.4.x ? How much is done?

comment:9 Changed 8 years ago by mikeperry

Some of these should probably be cleaned up/removed. Maybe in the process we should use a keyword rather than this parent ticket.

To more directly answer your question, the only thing I'm aiming to get into 0.2.4.x at this point is #7802 (which looks like it isn't even a child here, but maybe should be?).

comment:10 Changed 8 years ago by nickm

Okay; feel free to change the parent of #7802. Also remember that the small features deadline is real. :)

comment:11 Changed 8 years ago by mikeperry

Don't worry, I've been prioritizing tor-core deadlines higher than the remote code exec deadline of Firefox 10ESR. #7802 will take priority over any Firefox bugs from now till that deadline. Hope everyone has their fingers crossed. It's gonna be a close one :).

The parent of #7802 is already occupied though. That's the main reason I think we might want to switch to tags for these.

comment:12 Changed 8 years ago by mikeperry

Actually, since both deadlines are set in stone, I think #5956 is more important than Firefox 10ESR EOL at this point too (now that we have directory guards).

The good news though is that I think our 17ESR patches+Torbutton 1.5 is in a position to build a TBB alpha right now, so that may carry us for long enough with testing for me to get these two done. If not, I guess it a working 17ESR TBB-alpha just waits another week for me to do these two.

comment:13 Changed 8 years ago by nickm

Milestone: Tor: 0.2.4.x-finalTor: 0.2.5.x-final

Moving the remainder of this forward.

comment:14 Changed 7 years ago by nickm

Milestone: Tor: 0.2.5.x-finalTor: 0.2.???

comment:15 Changed 6 years ago by isis

Cc: isis added

comment:16 Changed 5 years ago by saint

Cc: saint added

comment:17 Changed 4 years ago by cass

Severity: Normal

This parent ticket is tagged SponsorZ, but it looks like progress on most open children stalled over a year ago and the two more-recently improved tickets (9001, 7003) might be being addressed under other proposals and work.

Should this still be an open SponsorZ ticket?

comment:18 Changed 4 years ago by nickm

Mikeperry probably has the best handle on the status of this.

comment:19 Changed 4 years ago by teor

Milestone: Tor: 0.2.???Tor: 0.3.???

Milestone renamed

comment:20 Changed 4 years ago by nickm

Keywords: tor-03-unspecified-201612 added
Milestone: Tor: 0.3.???Tor: unspecified

Finally admitting that 0.3.??? was a euphemism for Tor: unspecified all along.

comment:21 Changed 3 years ago by nickm

Keywords: tor-03-unspecified-201612 removed

Remove an old triaging keyword.

comment:22 Changed 3 years ago by nickm

Keywords: research-program added
Type: defectproject
Note: See TracTickets for help on using tickets.