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@gmail.com> wrote:

> Date: Sun, 3 May 2015 02:50:46 -0400
> From: CJ Ess <zxcvbn4038@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@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev