[tor-bugs] #12125 [Pluggable transport]: Proposal 232 (TOR_PT_PROXY) support for goptlib

Tor Bug Tracker & Wiki blackhole at torproject.org
Sun May 25 19:25:15 UTC 2014


#12125: Proposal 232 (TOR_PT_PROXY) support for goptlib
-------------------------------------+--------------------------
     Reporter:  dcf                  |      Owner:  dcf
         Type:  project              |     Status:  needs_review
     Priority:  normal               |  Milestone:
    Component:  Pluggable transport  |    Version:
   Resolution:                       |   Keywords:  goptlib
Actual Points:                       |  Parent ID:
       Points:                       |
-------------------------------------+--------------------------

Comment (by yawning):

 Replying to [comment:3 dcf]:
 > I'm thinking of doing even less validation of the URL, on the assumption
 that application authors know what they're doing and they're going to have
 to crawl the URL structure anyway to do anything useful. But the checks
 for credentials that won't work (like a password with socks4a, or too-long
 credentials with socks5) may be a good idea. On the other hand, I might
 like to let it fail at connect time, because the application has to check
 for errors at that time anyway.

 Hmmm, currently our connect time error reporting is all sorts of terrible,
 so I would rather PROXY-ERROR out on malformed URIs.  As long as
 `ProxyError` is exposed, leaving this up to the application would be fine.

 The proposal also says that the pluggable transports should connect to the
 proxy before `PROXY DONE`ing, which implies that validation is done at
 config time, but none of the existing implementations actually do the
 "connect before reporting" thing (IIRC I discussed this with asn when
 writing the patch and we came to the conclusion that just validating would
 be better because opening network connections on startup that aren't used
 is rude, and possibly identifiable behaviour).  This should be changed in
 the proposal.

 >
 [https://github.com/Yawning/obfs4/blob/c05a7a2e34dc832f192beaeee43931d13778dbe2/obfs4proxy/pt_extras.go#L144
 validateAddrStr] appears to allow only IP addresses, not host names. I
 guess prop 232 isn't clear whether host names need to be supported. I
 assumed they should be, without thinking about it. (The use case I'm
 thinking of is like a corporate proxy-only network, where you set your
 proxy to "!http://proxy.megacorp.example.com:8000/". I was also doing
 tests locally with "localhost".) I suppose this should be clarified in the
 proposal.

 This should be clarified in the proposal, yes.  For what it's worth, as it
 stands now, the code will always pass an IP address in the URI because tor
 does a `tor_addr_port_lookup` on each of the variables when parsing the
 config file (the URI format does say `ip`).  Allowing FQDNs would be more
 robust to changes on the tor side of the equation, but I am uncertain as
 to if this will change any time in the foreseeable future.

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


More information about the tor-bugs mailing list