Re: [tor-bugs] #10801 [Tor]: parse_bridge_line() does tor_addr_port_lookup(). Perhaps it should parse, not lookup.

["Tor Bug Tracker & Wiki" <blackhole@xxxxxxxxxxxxxx>]

#10801: parse_bridge_line() does tor_addr_port_lookup(). Perhaps it should parse,
not lookup.
------------------------+-------------------------------------
     Reporter:  nickm   |      Owner:
         Type:  defect  |     Status:  new
     Priority:  normal  |  Milestone:  Tor: 0.2.5.x-final
    Component:  Tor     |    Version:
   Resolution:          |   Keywords:  tor-client 024-backport
Actual Points:          |  Parent ID:
       Points:          |
------------------------+-------------------------------------

Comment (by dcf):

 I often use
 {{{
 Bridge tor1.bamsoftware.com:9001
 }}}
 when I'm testing things; I would have to memorize my bridge's IP address,
 but that's no big deal.

 Resolving the names at the time of parsing is indeed strange. I would be
 less surprised if the names were resolved at the time of the SOCKS
 connection, but that's fairly minor. If you assume that the name has to be
 resolved one way or another, it doesn't matter much when you resolve it,
 but some transports may not want the name to be resolved (or may want to
 resolve it in their own way).

 For me, it would be nice if Tor would pass unresolved host names to
 pluggable transports, and allow the pluggable transport to resolve it (or
 not). One use case is the mnemonic one above. Another is the new
 [[doc/meek|meek]] transport, which doesn't use a bridge IP address, but
 rather a URL:
 {{{
 Bridge meek 0.0.2.0:1 url=https://meek-reflect.appspot.com/
 front=www.google.com
 }}}
 The bridge address 0.0.2.0:1 is bogus and is ignored. The host name in the
 URL is resolved by the transport. Imagine instead:
 {{{
 Bridge meek meek-reflect.appspot.com:443 front=www.google.com
 }}}
 You can in fact write it this way now, but it won't work because Tor will
 pre-resolve the name, and the transport will receive only an IP address
 and will not know what to put in the Host header of its HTTP requests. I
 admit this case is not so compelling, because I wouldn't actually write it
 that way. A separate `url` argument allows you to include a path, which
 the hostname:port syntax doesn't. But for what it's worth, Tor passing
 host names to transports is what I assumed would happen when I started
 coding things, and I was surprised that it was resolving the names.

 It might be nice from a UX point of view if there was a way to indicate
 that the address field is going to be ignored, like with meek and flash
 proxy. A special invalid domain name could work for that (but is maybe not
 the best way).

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/10801#comment:2>
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