[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:  reopened           
    Priority:  normal       |   Milestone:  Tor: very long term
   Component:  Tor Client   |     Version:                     
  Resolution:               |    Keywords:                     
      Parent:               |      Points:                     
Actualpoints:               |  
----------------------------+-----------------------------------------------
Changes (by ioerror):

  * status:  closed => reopened
  * resolution:  wontfix =>


Comment:

 Replying to [comment:28 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.

 Ok, I've forked it and I'll take it under my wing.

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

 Sure, I think that is reasonable - I'm not sure that it makes sense to
 support _all_ of HTTP 1.1 if for example there is a subset that is
 commonly accepted for a non-caching proxy to implement, I'd shoot for that
 goal.

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

 Ok.

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

 Ah - there has been a long standing discussion with Mike about this topic.
 I think at this point I owe a large set of tickets to trac that outline
 the design I've drawn up. It has been in the queue, so I'll get it done
 sometime soon.

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

 I understand. I think that the key is the energy to be spent with changing
 your mind is a lot more than if you found the idea compelling. So in that
 sense, I feel like it is easier to simply spent that energy on this zygote
 design.

 It seems rather straight forward to me to provide the most minimal HTTP
 interface possible so as to reduce harm; that didn't convince you and
 largely because I offered shim as a thing to provide it.

 Shim is already a program, so that means it sounds like Tor is a launcher
 or some such thing. I understand why you wouldn't want Tor to just include
 another full program. Though I also think that could be fine, I don't
 think it is important enough to discuss further. I do think a thread that
 opens an HTTP port is that important but again, as it is a pretty serious
 uphill battle, I feel demotivated.

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

 I think a port that provides support for CONNECT is probably not too
 complicated and that is why I mentioned the DNSPort - we don't have to do
 everything but if we do something, we can do a lot of good, where
 otherwise, people are screwed or software just breaks badly.

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

 The main argument is one of harm reduction where today, TorBirdy will need
 to solve this problem, likely by becoming an HTTP proxy. We actually found
 some code from Moxie that will do the trick (and make us GPL, ironically).
 If Tor provided that, we'd just depend on Tor and we'd call it a day. That
 is how a JonDos user is kept safe.

 As an aside and part of why I'm working on the zygote is that TorBirdy
 will also likely have to include a Tor and be a Tor controller. That also
 means that if the user ever later installs Tor, they'll have two Tor
 clients on a given machine. We'll try to be smart but boy, we really do
 need to find a better solution.  In theory, we can have TorBirdy users run
 privoxy. In practice, other than Tails users and very advanced users, no
 one does it - so most users are in harms way, especially if they use GnuPG
 with TorBirdy (and SOCKS) or any other HTTP proxy only app.

 So the general issue for me is one of overall integration and the specific
 is one of proving a kind of interface, slightly different from what we
 already provide, because it would reduce harm. How we reduce that harm
 only matters in that it _must_ be zero config and not fail open.

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