Opened 20 months ago

Last modified 5 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:
Severity: Normal Keywords: ipv6, bridges, pluggable-transports, regression, 032-unreached
Cc: isis Actual Points:
Parent ID: Points: 0.2
Reviewer: dgoulet Sponsor:


This came to my attention through an old StackExchange ticket that the Community accound had bumped:

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 '' isn't reachable by our firewall policy. Skipping. 

This happens because they haven't defined 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 18 months 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


in addition to whatever other restrictions the user might set.

comment:2 Changed 18 months 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:

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 18 months ago by teor (previous) (diff)

comment:3 Changed 18 months ago by teor

Resolution: fixed
Status: closedreopened
Version: Tor:

Please see my branch bug19487 on

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

comment:4 Changed 18 months ago by teor

Status: reopenedneeds_review

comment:5 Changed 17 months ago by nickm

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

comment:6 Changed 17 months ago by nickm

Keywords: 029-proposed removed

comment:7 Changed 17 months ago by nickm

Cc: isis added

comment:8 Changed 17 months 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 17 months ago by dgoulet

Reviewer: dgoulet

actual-review-points: 0.1

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

Keywords: review-group-9 removed

comment:13 Changed 13 months ago by nickm

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

comment:14 Changed 9 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 9 months ago by nickm

Keywords: nickm-deferred-20161005 removed

comment:16 Changed 9 months ago by nickm

Keywords: CoreTorTeam201609 removed

comment:17 Changed 5 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.