[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