[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

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

#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
 addresses.
 >
 > 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:
 IPv6:
 {{{
     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 */
 }}}
 IPv4:
 {{{
     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 240.0.0.0/4 range?

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

 > Or the [https://tools.ietf.org/html/rfc5737 192.0.2.0/24 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 (224.0.0.0/4), 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 192.0.0.8/32 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: 192.0.2.0/24 (the others are
 198.51.100.0/24 and 203.0.113.0/24). 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
 future.

--
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
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs