Date: Sun, 3 May 2015 12:34:51 -0400 From: CJ Ess zxcvbn4038@gmail.com

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.

…

...

...

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

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.

Hi CJ,

There isn't a one-to-one correspondence between web browser SOCKS connections and Tor connections:

1. Each SOCKS connection results in a stream, and tor multiplexes multiple streams over multiple circuits through the same connection to the first hop in the path. 2. tor also initiates streams, such as directory fetches, without any corresponding SOCKS connection from the browser. 3. tor pre-emptively launches circuits, then uses them for client connections once a SOCKS request is received. 4. tor sometimes cannibalizes existing circuits by adding a hop to them.

tor makes a connection to 1-3 guard nodes, and those connections carry the majority of the web browser SOCKS traffic. They are authenticated at tor launch, before any browser makes a request, and I'm pretty sure that's it for authentication from then on.

If you could get authentication passthrough working, you'd still run into the following compatibility issues:

5. Tor Browser uses the input SOCKS username (I think) to manage stream-based isolation for different tabs, based on the URL. This would prevent you using Tor Browser with your modified version of tor, leaving you with a browser with fewer anonymity protections. 6. Some pluggable transports use the output proxy username to pass arguments. This would prevent you using pluggable transports with your modified version of tor.

And the following anonymity / usage issues:

7. If each SOCKS connection has a corresponding circuit, and you identify the user who initiated the circuit, you make it easier to de-anonymise the user behind the circuit. 8. Given that tor can multiplex multiple users over each circuit, who is responsible for bandwidth over-use?

If you're still keen on continuing, the closest that the socks authentication details get to where you need them is in conn->socks_request in circuit_get_open_circ_or_launch(). The call stack from then on is: circuit_launch_by_extend_info() circuit_establish_circuit() circuit_handle_first_hop() channel_connect_for_circuit() channel_connect() channel_tls_connect() connection_or_connect() Which initialises the or_connection_t struct "conn", then makes the connection to the proxy (if set). You could add the username and password to the conn data structure here.

When the connection has finished connecting, the callback is: connection_or_finished_connecting() Which calls: connection_proxy_connect() Which could then use the username and password from the conn data structure, if they exist - otherwise, it could use the default set in the config.

I still think you'll get the default authentication most of the time, because of tor's pre-emptive guard connections.

When you reply, can you avoid top-posting? Some mail clients top-post by default. But it's easier to follow the conversation if replies come after the initial email. Feel free to reply in the middle of the email as well.

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