[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 nickm):

 Replying to [comment:26 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?

 There is none; mine is the closest there is.

 > 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.

 Well, if it's going to claim to be an HTTP proxy, it should implement some
 version of HTTP. Probably 1.1?

 I don't know which specific security issues most affect http proxies.

 [...]
 > 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.

 Is *that* what #6948 was about? I have no idea what a zygote is, or why
 shared memory mutexes were something we needed, so I kinda assumed it was
 an 'implementation technique' ticket, not a 'better architecture' ticket.

  [...]
 > 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.

 Well, nothing is ''settled'' -- I can be wrong, and I hope I can change my
 mind if I am.

 But I don't think I'm wrong here.  HTTP is a very complex protocol, and I
 think about 100% of what you'd need to do with an HTTP proxy can be done
 out-of-process from Tor, as I understand it.

 If the only argument against a separate proxy is "but then you would have
 to run two programs", I don't think it's a great one, since having more
 processes is the direction we should IMO be moving towards, for better
 security and modularity.

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