[tor-bugs] #6060 [Tor Client]: add http proxy support to Tor

[Tor Bug Tracker & Wiki]

#6060: add http proxy support to Tor
-------------------------+--------------------------------------------------
 Reporter:  proper       |          Owner:  arma               
     Type:  enhancement  |         Status:  assigned           
 Priority:  normal       |      Milestone:  Tor: very long term
Component:  Tor Client   |        Version:                     
 Keywords:               |         Parent:                     
   Points:               |   Actualpoints:                     
-------------------------+--------------------------------------------------

Comment(by ioerror):

 Replying to [comment:23 nickm]:
 > Replying to [comment:16 ioerror]:
 > > Replying to [comment:15 nickm]:
 > > > "Audit shim and bring it up-to-date" is a reasonable thing to do.
 > >
 > > I'm not sure what it needs - it compiles without warnings (yay) and it
 seems to function just as it should. It looks "finished" in as much as any
 C program. :)
 > >
 > > It does need compiler hardening and all that stuff added, of course.
 >
 > What it needs IMO is auditing for security and standards compliance.

 Ok - I think both of those are reasonable. What is the absolute canonical
 git repo? Is it yours? If so, I'd be willing to perform both of those
 audits. I would like some guidance of which standards matter to us and
 what specific security issues that concern us.

 I assume we want to consider the security issues of a program written in
 C; {buffer,heap,int} overflows, format strings, {double,use after}free(),
 etc.

 I also assume we'd want to ensure that the HTTP/1.1 standard is followed
 as much as is possible as far as shim's clients are concerned. I don't
 know of any standard that regulates HTTP->SOCKS4a proxies, so I think
 we're flying by the seat of our pants there. :)

 Any requirements of such a thing - regardless of where we put it - I'm
 open to considering and trying to resolve.

 >
 > > > Somebody would need to take on the responsibility of being shim
 maintainer.  I don't know that shipping shim by default would make senese.
 > >
 > > The open question for me is - "what would it take to make an HTTP
 proxy port a Tor configuration line as we have with SOCKSPort?"
 >
 > For me, that's not a goal.  Tor is not an all-singing all-dancing all-
 purpose application launcher, nor do I want to push '''more''' code into
 the main Tor process.  I'd like us to move in the direction of moving
 functionality ''out'' of Tor.
 >

 Ok, I think our goals aren't so different here. I don't want a full HTTP
 proxy with caching - I want the most minimal thing that will help reduce
 harm for our users. I think there is a balance to be struck and that is
 what happened with DNSPort - it is a minimal thing that at least gives
 '''some''' of the features that our users need. It has been extremely
 handy, even if imperfect or limited; it isn't standards compliant but holy
 cow, it is useful!

 I am hoping to solve this with a clean design in #6948 - so I totally hear
 you. I'm '''also''' in favor of that as a reality, sooner rather than
 later. If we can solve #6948, I would say we could break out each of these
 things quite nicely and move more and more code out of Tor proper. I am
 totally a fan of that '''while''' also being concerned that we may not
 succeed anytime soon.

 > > It seems to me that the _easy_ way is to have a shim binary component
 and just run it. That isn't the cleanest way, I guess. A feature for
 0.2.4.x, perhaps?
 > >
 > > It seems to me that the _best_ way is to have Tor do the entire thing
 in a thread or internally in some other way. A feature for 0.2.4.x or
 0.2.5.x, I guess.
 > >
 > > nickm - Which way seems reasonable? If the proxy code was inside of
 Tor - would that be reasonable? Or do you outright reject the idea? :)
 >
 > Strongly reject.  Tor is not inetd; Tor is not systemd.  "It could be in
 tor" and "applications could use it" are not a justification for putting
 it in Tor.
 >

 Ok. That settles it, I guess. If both options are rejected, even as a
 thread that doesn't loop to a SocksPort, I'll continue with designs in
 #6948.

 > We *do* need a better way to handle the multiple pieces of the Tor
 experience, but "do everything in Tor" is exactly the wrong answer.

 Perhaps some hybrid choices exist that might satisfy us both? I'm open to
 finding any kind of middle ground that might reduce harm to users (such as
 those that suffer from the gpg bug #2846) - if that means I need to write
 a tiny launcher like in #6948, Ok!

 I think the clear take away is that Tor will probably not have an HTTPPort
 like we a SocksPort or a DNSPort. I accept that reality and I will work on
 #6948 unless there is a hybrid choice that you propose.  If there is no
 such hybrid notion that would be reasonable to get into 2.4.x or
 '''later''', I'd ask that we close the ticket and add an FAQ item.

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