Opened 2 years ago

Last modified 12 months ago

#19487 needs_revision defect

Meek and ReachableAddresses

Reported by: cypherpunks Owned by: dcf
Priority: Medium Milestone: Tor: unspecified
Component: Core Tor/Tor Version: Tor: 0.2.8.2-alpha
Severity: Normal Keywords: ipv6, bridges, pluggable-transports, regression, 032-unreached
Cc: isis Actual Points:
Parent ID: Points: 0.2
Reviewer: dgoulet Sponsor:

Description

This came to my attention through an old StackExchange ticket that the Community accound had bumped: http://tor.stackexchange.com/q/9500

The user appears to have setup some combination of ReachableAddresses,FirewallPorts, and FascistFirewall. While the ports they can reach might be set correctly, when using meek tor sees the destination address as a fake destination. You end up with a log that looks like this:

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

This happens because they haven't defined 0.0.2.0:1 as being a reachable address, while in reality it's using (most likely) port 443 on some CDN, which might actually be defined reachable.

Maybe not a common issue but an interesting edge case that may be clarified, avoided, or documented somewhere.

Child Tickets

Change History (17)

comment:1 Changed 2 years ago by dcf

Resolution: fixed
Status: newclosed

Thanks for this ticket. I added a comment to another ticket that's about tor's handling of dummy addresses in general: comment:4:ticket:18611.

I also added a new section to the wiki page: doc/meek#Troubleshooting.

I suppose one solution is that Orbot et al. could just hard-code

ReachableAddresses 0.0.2.0

in addition to whatever other restrictions the user might set.

comment:2 Changed 2 years ago by teor

Component: Obfuscation/meekCore Tor/Tor
Keywords: ipv6 bridges pluggable-transports regression 029-proposed CoreTorTeam201609 added
Milestone: Tor: 0.2.???
Points: 0.2
Version: Tor: 0.2.8.1-alpha

Tor can't know the actual address that a pluggable transport connects to, unless the pluggable transport tells it. And the pluggable transport protocol doesn't do that, as far as I know.

So I believe the correct long-term fix here is for Tor to treat all bridges with transports like SOCKS or HTTP proxies, and warn when their addresses aren't reachable, but try anyway, rather than failing.

Last edited 2 years ago by teor (previous) (diff)

comment:3 Changed 2 years ago by teor

Resolution: fixed
Status: closedreopened
Version: Tor: 0.2.8.1-alphaTor: 0.2.8.2-alpha

Please see my branch bug19487 on https://github.com/teor2345/tor.git

It stops applying ReachableAddresses to bridges with pluggable transports, and updates the documentation to match Tor's actual behaviour.

comment:4 Changed 2 years ago by teor

Status: reopenedneeds_review

comment:5 Changed 2 years ago by nickm

Keywords: review-group-9 added
Milestone: Tor: 0.2.???Tor: 0.2.9.x-final

comment:6 Changed 2 years ago by nickm

Keywords: 029-proposed removed

comment:7 Changed 2 years ago by nickm

Cc: isis added

comment:8 Changed 2 years ago by dgoulet

Status: needs_reviewneeds_revision

In fetch_bridge_descriptors(), iiuc we log notice with a firewall policy message if the bridge transport is not reachable but then we'll try anyway. I think that will only bring confusion because why do we warn in the first place if the firewall policy doesn't apply to transport?

Would having this be enough? That is, we only check firewall policy if it's _not_ a transport or if we should ask directly and firewall policy checks out?

      if (!bridge->transport_name ||
          (ask_bridge_directly &&
           !fascist_firewall_allows_address_addr(&bridge->addr, bridge->port,
                                                 FIREWALL_OR_CONNECTION, 0,
                                                 0))) {

And also, doesn't the ask_bridge_directly must really be set to 1 if we have a transport? Not too familiar with this part of the code but I don't think we want "fetch descriptor directly from bridge" if a transport is set. If so, we could reinforce how ask_bridge_directly = ... is set I guess?

comment:9 Changed 2 years ago by dgoulet

Reviewer: dgoulet

actual-review-points: 0.1

comment:10 Changed 2 years ago by nickm

Keywords: nickm-deferred-20161005 added
Milestone: Tor: 0.2.9.x-finalTor: 0.3.0.x-final

Deferring big/risky-feature things (even the ones I really love!) to 0.3.0. Please argue if I'm wrong.

comment:11 Changed 2 years ago by nickm

These have sat in needs_revision for a few weeks at least. Removing from review-group-9, not adding to review-group-10.

comment:12 Changed 2 years ago by nickm

Keywords: review-group-9 removed

comment:13 Changed 20 months ago by nickm

Milestone: Tor: 0.3.0.x-finalTor: 0.3.1.x-final

comment:14 Changed 16 months ago by nickm

Milestone: Tor: 0.3.1.x-finalTor: 0.3.2.x-final

0.3.1 feature freeze today: these don't seem like they will be all sorted out in time. Let's try to make progress in 0.3.2.

comment:15 Changed 16 months ago by nickm

Keywords: nickm-deferred-20161005 removed

comment:16 Changed 16 months ago by nickm

Keywords: CoreTorTeam201609 removed

comment:17 Changed 12 months ago by nickm

Keywords: 032-unreached added
Milestone: Tor: 0.3.2.x-finalTor: unspecified

Mark a large number of tickets that I do not think we will do for 0.3.2.

Note: See TracTickets for help on using tickets.