Opened 8 years ago

Last modified 2 years ago

#2998 new defect

If your bridge is near your exit, Tor might surprise you by failing your circuit

Reported by: arma Owned by:
Priority: Medium Milestone: Tor: unspecified
Component: Core Tor/Tor Version:
Severity: Normal Keywords: tor-bridge, prop247, needs-proposal
Cc: Actual Points:
Parent ID: Points: medium
Reviewer: Sponsor:

Description

In fixing #1090, we removed the logic that said "if your exit relay and your bridge are on the same /16, and you were about to fail the circuit, ignore the distinctsubnets constraint". This could result in surprising failures for bridge users.

The origin of the problem is that #1090 decides to follow the user's instructions even when we think they were bad instructions, because the user asked for the behavior explicitly. And I agree with that plan in the case of setting EntryNodes. But a user who sets Bridges might be doing it because he only knows about those bridges, not because he thinks he knows something about path selection strategy that the Tor developers don't know.

So do we keep the user safe by failing any circuits whose exit relays are near her bridges? ("you asked for that behavior, so you get it, sucks to be you") Or do we focus on reachability and back off on our path selection constraints?

One option might be to use the "do I want security or do I want reachability" config option we've been heading toward with #2510 and #2511: if we let the bridge cache and try to use bridges that aren't currently configured, we could also make current bridges work rather than fail in this situation.

The Tor client will pick a new exit and try another circuit, so the main effect of the bug is added latency for circuit creation. But there's a slight possibility that we will give up on circuits for an entire minute (after 5 failures). How often does this edge case occur in practice? What if it starts occurring later?

I worry because none of the developers use bridges so few people fix bridge robustness issues.

Child Tickets

Change History (12)

comment:1 Changed 8 years ago by nickm

Milestone: Tor: 0.2.3.x-finalTor: unspecified

Trying to fix this logic in 0.2.3.x feels likely to be destabilizing, and since we currently (if I read you right) fail closed, I'm okay with putting this into Tor: Unspecified.

comment:2 Changed 7 years ago by nickm

Keywords: tor-bridge added

comment:3 Changed 7 years ago by nickm

Component: Tor BridgeTor

comment:4 Changed 4 years ago by arma

Severity: Normal

#16437 is an example of a real live user experiencing this bug, except it's where his client used an HSDir or an intro point or something of the hidden service he was trying to visit, and it overlapped with his bridge address so the circuit failed.

comment:5 Changed 4 years ago by teor

This allows bridge clients to be distinguished from regular clients: bridge clients will fail a circuit if their bridge is near the exit / intro point / rend point, but clients won't fail a circuit if they are near their endpoint.

comment:6 Changed 4 years ago by teor

Keywords: prop247 added
Milestone: Tor: unspecifiedTor: 0.2.9.x-final

I suspect we will need to rethink this scenario as we work on the guard proposals: prop#247 and the like.

comment:7 Changed 4 years ago by nickm

Points: medium

comment:8 Changed 4 years ago by isabela

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

tickets market to be removed from milestone 029

comment:9 Changed 3 years ago by teor

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

Milestone renamed

comment:10 Changed 3 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:11 Changed 2 years ago by nickm

Keywords: tor-03-unspecified-201612 removed

Remove an old triaging keyword.

comment:12 Changed 2 years ago by nickm

Keywords: needs-proposal added
Note: See TracTickets for help on using tickets.