[tbb-bugs] #18517 [Tor Browser]: meek is broken in Tor Browser 6.0a3

Tor Bug Tracker & Wiki blackhole at torproject.org
Sun Mar 20 10:22:19 UTC 2016

#18517: meek is broken in Tor Browser 6.0a3
 Reporter:  gk           |          Owner:  tbb-team
     Type:  defect       |         Status:  new
 Priority:  Very High    |      Milestone:
Component:  Tor Browser  |        Version:
 Severity:  Normal       |     Resolution:
 Keywords:  regression   |  Actual Points:
Parent ID:               |         Points:
 Reviewer:               |        Sponsor:  None

Comment (by teor):

 Replying to [comment:5 dcf]:
 > Replying to [comment:4 teor]:
 > > I think this is a Tor Browser issue and we should adopt dcf's
 workaround of changing the dummy IP addresses to publicly routable IP
 > Could we get some guidance on what false IP addresses to use? It's a
 flaw in the PT spec that bridge specifications have to have an IP address,
 even if the transport doesn't use it. I tried to make the IP addresses as
 fake-looking as possible, to try and make it obvious that they are unused.

 The relevant lists of internal addresses in tor_addr_is_internal_ are:
     if (for_listening && !iph6[0] && !iph6[1] && !iph6[2] && !iph6[3]) /*
 :: */
       return 0;

     if (((iph6[0] & 0xfe000000) == 0xfc000000) || /* fc00/7  - RFC4193 */
         ((iph6[0] & 0xffc00000) == 0xfe800000) || /* fe80/10 - RFC4291 */
         ((iph6[0] & 0xffc00000) == 0xfec00000))   /* fec0/10 D- RFC3879 */
       return 1;

     if (!iph6[0] && !iph6[1] && !iph6[2] &&
         ((iph6[3] & 0xfffffffe) == 0x00000000))  /* ::/127 */
     if (((iph4 & 0xff000000) == 0x0a000000) || /*       10/8 */
         ((iph4 & 0xff000000) == 0x00000000) || /*        0/8 */
         ((iph4 & 0xff000000) == 0x7f000000) || /*      127/8 */
         ((iph4 & 0xffff0000) == 0xa9fe0000) || /* 169.254/16 */
         ((iph4 & 0xfff00000) == 0xac100000) || /*  172.16/12 */
         ((iph4 & 0xffff0000) == 0xc0a80000))   /* 192.168/16 */

 > I don't think it's a good idea the IP address of whatever relay the PT
 eventually carries the traffic to, because it's not reflective of what's
 going on. If the bridge changes its IP address, the bridge line will keep
 working with the "wrong" address, and that's likely to be confusing.

 I agree. And you run the risk that the actual address is unavailable to
 Tor Browser, or that you retrieve the remote address and it's an internal
 address, and therefore blocked.

 > Could we use something in e.g. the reserved range?

 I'd advise against this, in case it's released for public use, or

 > Or the [https://tools.ietf.org/html/rfc5737 range reserved
 for examples]? Maybe a bogus IPv6 address?

 Yes, either of these options will currently be accepted by tor (return 0
 from tor_addr_is_internal).

 Over the long term, the list of internal addresses in tor may be expanded.
 It's worth selecting an address that we'll never include in that list, so
 we don't have to revisit this issue in a later release. (The most likely
 to be included in future is multicast (, which we already
 block in some places in the code.)

 Ideally, Tor Browser would use an address blackholed at the OS level, so
 we never have to or want to block it in tor. But there's nothing like this
 in IPv4, and IPv6 potentially routes its blackhole range to an IDS, which
 we never want to happen, even by accident.

 It's worth noting that RFC 7600 reserves as a dummy address,
 but only for the purpose of the IPv6 transition. So let's not use that,
 because it could be confusing. (See https://www.iana.org/assignments/iana-
 ipv4-special-registry/iana-ipv4-special-registry.xhtml )

 Let's use the first documentation range: (the others are and They're not exactly what we want, but
 they should be usable as a generic dummy address. Let's document the range
 we choose in the pluggable transport spec (this ticket?), and the tor
 source code (#18582), so we handle those addresses appropriately in

Ticket URL: <https://trac.torproject.org/projects/tor/ticket/18517#comment:6>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online

More information about the tbb-bugs mailing list