Opened 6 years ago

Closed 5 years ago

Last modified 3 years ago

#9777 closed defect (implemented)

Retry your path selection if you don't get an NTor-supporting relay in it?

Reported by: arma Owned by:
Priority: High Milestone: Tor: 0.2.4.x-final
Component: Core Tor/Tor Version:
Severity: Keywords: tor-client, 024-backport, security, 2016-bug-retrospective
Cc: iang Actual Points:
Parent ID: Points:
Reviewer: Sponsor:


Currently Tor chooses its path as normal, and then it decides for each relay whether it will send a TAP or NTor.

Coupled with the use of CREATE_FAST for the first hop, that means if you flip two (weighted) coins wrong, you're building a circuit that's worth attacking by an adversary who finds breaking 1024-bit crypto doable.

By my count, the current consensus aggregate weight for various relay versions is:

0.2.2.x: 351110
0.2.3.x: 4036995
0.2.4.x: 6361554
0.2.5.x: 285012

So oversimplifying grossly, that's a 40% squared = 16% chance of flipping those coins wrong given the current network.

But even in a world where 90% of the relay capacity has upgraded, that's still a 1% chance of an all-TAP circuit. Not so good.

(Implementing proposal 221 would help here, but not make the problem go away entirely.)

I think we should have a config option, probably set to auto and controlled by the consensus, to flip our coins again if we're not going to send an NTor cell to any of the relays in our path.

Unless we want to decide that users should always want it, and not even make it a config option or consensus param? I don't think we should do that at least until we've calculated the actual odds of all all-TAP path. They could actually be quite a bit higher than 16% now, since your Guards are discounted as a function of the scarcity of guard bandwidth, and a lot of middle relays are small and a lot of small relays haven't upgraded yet. In that case turning on this 'pick another path' feature could significantly impact anonymity too.

I wonder how sad 0.2.4 users would be if they don't get this feature. Probably pretty sad. So, setting to 0.2.4 but that's up for debate.

Child Tickets

Change History (12)

comment:1 Changed 6 years ago by nickm

Keywords: 024-backport security added
Milestone: Tor: 0.2.4.x-finalTor: 0.2.5.x-final
Priority: normalmajor

This smells like an 0.2.5 thing for me, but i'll mark for possible backport.

comment:2 Changed 6 years ago by iang

Cc: iang added

comment:4 Changed 6 years ago by arma

I talked Nick into thinking this is an 0.2.4 feature after all.

We should probably test it in 0.2.5 for a release before backporting though (since there is no patch quite yet).

comment:5 Changed 6 years ago by nickm

Status: newneeds_review

This is branch feature9777_024 .

comment:6 Changed 6 years ago by arma

Branch looks like it should work. Thanks!

The redundancy between circuit_clear_cpath() and circuit_free_cpath() is still bugging me though. Why not change circuit_free_cpath() to take in an origin_circuit_t, and then change the one place that calls it, and then we don't have two functions?

comment:7 Changed 6 years ago by nickm

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

Okay, the branch is now feature9777_024_squashed.

I'll refactor that circuit_free_cpath stuff after merging it into 0.2.5 (which I'm doing now). Putting this in the 0.2.4 milestone for backport assuming nothing breaks in 0.2.5.

comment:8 Changed 6 years ago by arma

Merging to 0.2.4 sounds good to me

comment:9 Changed 5 years ago by nickm

Resolution: implemented
Status: needs_reviewclosed

Merged to 0.2.4.

comment:10 Changed 3 years ago by nickm

Keywords: 2016-bug-retrospective added

Mark bugs for 2016 bug retrospective based on hand-examination of changelogs for 0.2.5 onwards.

comment:11 Changed 3 years ago by nickm

Mark bugs for 2016 bug retrospective based on hand-examination of changelogs for 0.2.5 onwards.

comment:12 Changed 3 years ago by nickm

Mark bugs for 2016 bug retrospective based on hand-examination of changelogs for 0.2.5 onwards.

Note: See TracTickets for help on using tickets.