[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-bugs] #6060 [Tor]: add http proxy support to Tor
#6060: add http proxy support to Tor
----------------------------+-----------------------------------------------
Reporter: proper | Owner: arma
Type: enhancement | Status: reopened
Priority: normal | Milestone: Tor: very long term
Component: Tor | Version:
Resolution: | Keywords: tor-client
Parent: | Points:
Actualpoints: |
----------------------------+-----------------------------------------------
Comment(by fk):
It has been brought to my attention that somebody is wrong on the Internet
and I'm here to help.
Privoxy has been able to leverage Tor's stream separation by using
separate socks ports for years. It's commonly done by request tagging, I
rely on it every day to separate Firefox, fetch, curl and various other
clients I use and it is working (for me) as expected:
http://config.privoxy.org/user-manual/actions-file.html#CLIENT-HEADER-
TAGGER
While there is currently no IsolateSOCKSAuth support, that's mainly
because nobody cared enough to provide patches as stream separation is
already available through other means:
http://sourceforge.net/tracker/?func=detail&aid=3541363&group_id=11118&atid=361118
Even if this wasn't the case, I don't think the paraphrased argument
"Privoxy and Polipo suck, therefore Tor needs to act as HTTP proxy" is a
particular good one.
If the Tor project really wants to reverse the current policy and ship a
HTTP proxy with Tor again, I think it would be worth trying to communicate
with the various HTTP proxy upstreams about what the requirements are, to
see if they can be satisfied already or maybe in a future release after
adding the missing pieces (potentially by accepting the required patches).
It's water under the bridge, but in my opinion the Tor project has a
pretty poor track record when it comes to working with HTTP proxy
upstreams and especially the recent number it did on Juliusz probably
didn't help to instill goodwill in general.
As far as native HTTP proxy support in Tor is concerned, I agree with Jake
that a HttpPort implementation that only supports CONNECT requests would
be comparably trivial to implement, but like to point out that most HTTP
clients have no support for tunneling http:// requests through HTTP
proxies by using CONNECT. And those that do probably already support
socks5 anyway.
One of the obvious risks of implementing support for HTTP methods other
than CONNECT without constantly monitoring and parsing the arriving data
(which requires implementing a significant amount of RFC2616) would be
requests on a reused connection ending up at the wrong server.
Nowadays some clients aggressively pipeline requests right away instead of
waiting for the first response as "suggested" in the standard and in this
case the old "trick" of changing the Connection header in the first
arriving request to "Connection: close" and trusting without properly
verifying that client and server respect it no longer cuts it.
Full disclosure: it's "fk" as in "Fabian Keil" and I'm obviously biased.
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/6060#comment:39>
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