Meek and ReachableAddresses

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.

changed milestone to %Tor: unspecified

added 032-unreached bridges component::core tor/tor ipv6 meek milestone::Tor: unspecified owner::dcf pluggable-transports points::0.2 priority::medium regression reviewer::dgoulet severity::normal status::needs-revision type::defect version::tor 0.2.8.2-alpha labels

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.

Trac:
Resolution: N/A to fixed
Status: new to closed

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.

Trac:
Component: Obfuscation/meek to Core Tor/Tor
Version: N/A to Tor: 0.2.8.1-alpha
Keywords: N/A deleted, bridges, CoreTorTeam201609, pluggable-transports, 029-proposed, regression, ipv6 added
Points: N/A to 0.2
Milestone: N/A to Tor: 0.2.???

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.

Trac:
Resolution: fixed to N/A
Status: closed to reopened
Version: Tor: 0.2.8.1-alpha to Tor: 0.2.8.2-alpha

Trac:
Status: reopened to needs_review

Trac:
Keywords: N/A deleted, review-group-9 added
Milestone: Tor: 0.2.??? to Tor: 0.2.9.x-final

Trac:
Keywords: 029-proposed deleted, N/A added

Trac:
Cc: N/A to isis

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?

Trac:
Status: needs_review to needs_revision

actual-review-points: 0.1

Trac:
Reviewer: N/A to dgoulet

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

Trac:
Milestone: Tor: 0.2.9.x-final to Tor: 0.3.0.x-final
Keywords: N/A deleted, nickm-deferred-20161005 added

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

Trac:
Keywords: review-group-9 deleted, N/A added

Trac:
Milestone: Tor: 0.3.0.x-final to Tor: 0.3.1.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.

Trac:
Milestone: Tor: 0.3.1.x-final to Tor: 0.3.2.x-final

Trac:
Keywords: nickm-deferred-20161005 deleted, N/A added

Trac:
Keywords: CoreTorTeam201609 deleted, N/A added

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

Trac:
Milestone: Tor: 0.3.2.x-final to Tor: unspecified
Keywords: N/A deleted, 032-unreached added

Trac:
Keywords: N/A deleted, meek added

changed time estimate to 1h 36m

mentioned in issue #33693 (moved)

moved to tpo/core/tor#19487 (closed)