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/24f170a11f59e26dec3a24d076b749c8acc79...
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
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/24f170a11f59e26dec3a24d076b749c8acc79...
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 freeto 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 freeto 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
-
CJ Ess -
teor