[tor-dev] working back to socks_request_t

[CJ Ess]

So underlying idea in this case is to pass thru the proxy credentials from
the browser, so they don't have to be had coded in plain text in the tor
config - you exit the browser and the credential goes away (or maybe its
encrypted in the browser password manager), if you change your password you
don't have to go update the tor config and bounce it, if its a shared
device you don't have to reconfigure and possibly leave your credentials
around, etc.

That sounds good conceptually, but to implement I somehow need to work back
from the connection_t passed into the function I mentioned to something
that has the socks info (circuit? associated edge connection?) I tried to
trace it though and nothing jumped out at me but maybe there is some type
casting happening and I'm missing it. The other option would be to pass the
info down through extra arguments or copied into extra field members.
Either way I'm speculating there might be a really simple way to do this
and worth the time writing up the question. If I get it working I'd be
happy to send in a patch to the this list.


On Sun, May 3, 2015 at 11:06 AM, teor <teor2345 at gmail.com> wrote:

>
> > Date: Sun, 3 May 2015 02:50:46 -0400
> > From: CJ Ess <zxcvbn4038 at gmail.com>
> >
> > So I'm doing a bit of an experiment, the idea being that if you have a
> > group of tor users sharing common infrastructure then its a slightly
> > different situation then one lone user, and you wantto emphasize that
> > resources should not be shared, caching should be minimal and
> > non-persistent, you need to keep usage from standing out, etc. The
> problem
> > with my original idea is that everything that does HTTP <> SOCKS is one
> or
> > two decades old, and draws a lot of attention because it forks for every
> > connection or is some strange process that nobody has ever seen before.
> >
> > So plan B is everyone involved runs their socks speaking browser on their
> > desktop/laptop, everyone runs a tor client on the same device as their
> > browser, we use the HTTPProxy/HTTPSProxy feature of the clients to
> navigate
> > the firewall, everyone uses their own credentials instead of having one
> ID
> > draw attention for high utilization, and the presence of
> > the Proxy-Authorization header takes care of any caching/session sharing
> > issues along the way.
> >
> > To make that work, the one question I have for tor-dev is if its possible
> > Here:
> >
> >
> https://github.com/torproject/tor/blob/24f170a11f59e26dec3a24d076b749c8acc793ca/src/or/connection.c#L1865
> >
> > To work back to the socks_req, so that I can pass through the username
> and
> > password to the upstream proxy instead of the one global
> username/password?
>
> Hi CJ,
>
> It sounds like you're looking for one of the HTTP(S)ProxyAuthenticator
> options - you can configure a different username and password in the torrc
> file on each client's desktop/laptop.
>
> If you are going to run a SOCKS-speaking browser, why not run the Tor
> Browser?
> It does a lot more to protect your anonymity than most.
>
> From the tor manual page:
>
>        HTTPProxyAuthenticator username:password
>            If defined, Tor will use this username:password for Basic HTTP
>            proxy authentication, as in RFC 2617. This is currently the only
>            form of HTTP proxy authentication that Tor supports; feel free
> to
>            submit a patch if you want it to support others.
>
>        HTTPSProxyAuthenticator username:password
>            If defined, Tor will use this username:password for Basic HTTPS
>            proxy authentication, as in RFC 2617. This is currently the only
>            form of HTTPS proxy authentication that Tor supports; feel free
> to
>            submit a patch if you want it to support others.
>
> If these options aren't what you're looking for, can you explain what you
> want done with the SOCKS request in a bit more detail?
>
> teor
>
> teor2345 at gmail dot com
> pgp 0xABFED1AC
> https://gist.github.com/teor2345/d033b8ce0a99adbc89c5
>
> teor at blah dot im
> OTR D5BE4EC2 255D7585 F3874930 DB130265 7C9EBBC7
>
>
> _______________________________________________
> tor-dev mailing list
> tor-dev at lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20150503/8445a489/attachment.html>