Opened 19 months ago

Last modified 4 months ago

#18611 new defect

Improve semantics for pluggable transports with dummy addresses

Reported by: teor Owned by:
Priority: Medium Milestone: Tor: unspecified
Component: Core Tor/Tor Version:
Severity: Normal Keywords: tor-pt configuration ptv2 meek
Cc: Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

In #18517, we noted that some pluggable transports (for example, meek) use a dummy IP address in the bridge line, because the actual addresses are specified using some other method.

The address specified in the bridge line is passed by tor to the pluggable transport, which then ignores it. But there's no way for tor to know whether the address is going to be ignored.

Ignoring an address has a number of implications:

  • there's no standard IPv4 or IPv6 "dummy" address
  • even if two bridge lines use the same "dummy" address and port, bridge_resolve_conflicts should not consider them to be conflicting

(Are there any more?)

  • anything that checks the address of the bridge will return erroneous results

I'm not sure there's any easy way of fixing this, but I'm writing it down so we know about it. Perhaps it needs a change to the semantics of the bridge line so we can leave out address and port if they're going to be ignored anyway.

Child Tickets

Change History (8)

comment:1 Changed 19 months ago by dcf

Keywords: meek added

Snowflake is going to want to use dummy addresses in the same way, because the connection is indirect over WebRTC through some random web browser proxy.

comment:2 Changed 19 months ago by nickm

This is related to a part of the overall PT-related design ideas I've been talking to with Ben Schwartz of uProxy.

Basically, having the "destination address" implicit and the "proxy address" explicit was probably a mistake, and we kinda have a transition plan, if we ever get around to making it happen.

comment:3 in reply to:  2 Changed 19 months ago by yawning

Hm, I'd need to look at the conflict resolution stuff. I assume the ideal behavior is "non-conflicting as long as at least one of transport, ip/port, fingerprint is different". This is sort of a moot point because existing 0.2.7.x behavior is going to be preserved (As in, internal address/ports specified on a bridge line do not get rejected).

Replying to nickm:

Basically, having the "destination address" implicit and the "proxy address" explicit was probably a mistake, and we kinda have a transition plan, if we ever get around to making it happen.

*bangs head on keyboard* I still think the current model is fine.

comment:4 Changed 14 months ago by dcf

Here's another little bug we didn't think of: #19487 "Meek and ReachableAddresses."

If the dummy address doesn't match ReachableAddresses (or FascistFirewall, etc.), then Tor will ignore it with a log:

NOTICE: Bridge at '0.0.2.0:1' isn't reachable by our firewall policy. Skipping.

This is another case (like #18611) where it would be nice to be able to indicate to tor that an address is not real, and not to consider it when making decisions about reachability.

comment:5 Changed 11 months ago by teor

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

Milestone renamed

comment:6 Changed 10 months 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:7 Changed 5 months ago by nickm

Keywords: tor-03-unspecified-201612 removed

Remove an old triaging keyword.

comment:8 Changed 4 months ago by nickm

Keywords: tor-pt configuration ptv2 added
Note: See TracTickets for help on using tickets.