search

nyxnor / tor-ctrl

Raw use of tor's controller
Other
5 stars 3 forks source link

connect to Tor provided by the Tor Browser Bundle (TBB) #27

Closed adrelanos closed 2 years ago

adrelanos commented 2 years ago

Is it possible to use tor-ctrl also to interact with provided by the Tor Browser Bundle (TBB)?

That would be useful. Next ticket will explain why.

nyxnor commented 2 years ago

Yes. This is what I do:

  1. Start TBB but do not attempt connections (do not click on the purple button).
  2. The controlport is now opened as 127.0.0.1:9151, but the network is disabled by DisableNetwork 1
  3. Run the given coomand with tor-ctrl with tor-ctrl -s 9151 COMMAND.
  4. Tcharam.

I default to not attempting to connect to the network automatically, this way I can see the first streams, as in reaching mozzilla, securedrop and other hosts.

This is what I used on debian, need to retest on whonix.

nyxnor commented 2 years ago

on debian: specify control port 9151 with -s 9151 on whonix: no need to specify socket (ran on gateway and it detected /run/tor/control)

adrelanos commented 2 years ago

Cool!

Could you add to documentation please? Connecting to TBB's Tor ControlPort seems pretty much undocumented online.

Or better: possible to auto-detect TBB too? Better usability for users.

nyxnor commented 2 years ago

Could you add to documentation please? Connecting to TBB's Tor ControlPort seems pretty much undocumented online.

Yes, tor-ctrl can connect to any tor socket, TBB or tor daemon.

Or better: possible to auto-detect TBB too? Better usability for users.

On Whonix it already autodetects. On debian:

I prefer adding documentation because of this, to avoid defaulting TBB socket.

adrelanos commented 2 years ago

Why should it prefer TBB socket instead of the installed tor?

Indeed. Don't prefer TBB socket over system Tor socket. But if there is no system Tor, does tor-ctrl auto detect and connect to TBB socket?

nyxnor commented 2 years ago

But if there is no system Tor, does tor-ctrl auto detect and connect to TBB socket?

Not yet but could use netcat to scan open ports. The only port it would scan is default 9151 for TorBrowser, as it is the only one I see reason. Or could even try the enviroment variables TOR_CONTROL_HOST and TOR_CONTROL_PORT.

adrelanos commented 2 years ago

That would be great!

nyxnor commented 2 years ago

done in commit c69df4c1d8149e71813334b343fc0e8ce2e7e71e

nyxnor commented 2 years ago

broke extra scripts. Main script is trying fs socket, then tbb socket, then env vars. But extra scripts are just trying the first socket.

How to test on debian:

return from the function is not working.

$ ./tor-ctrl-circuit 
tor-ctrl: nc: Connetion refused to 127.0.0.1:9051
tor-ctrl-circuit: [warn] Do not share this information publicly, it could deanonymize yourself.

tor-ctrl-circuit: [warn] Do not share this information publicly, it could deanonymize yourself.
$ ./tor-ctrl GETCONF user
tor-ctrl: [info]: connecting to socket with command: nc 127.0.0.1 9151
250 OK
250 User
250 closing connection
nyxnor commented 2 years ago

nevermind, I was running from source and not installed the newest commits, so having troubles.

Will add more commits related to information about what socket you are connected to, so you don't get confused. If you have TBB and tor daemon running, you need to specifiy -s 9151 to prefer TBB before tor daemon. If tor daemon is not running, then no problem, it will only try the TBB socket.

nyxnor commented 2 years ago

Question: If the socket is specified on the command line, should it only try that socket and fail or continue the same process of trying other sockets?

adrelanos commented 2 years ago

nyxnor:

broke extra scripts. Main script is trying fs socket, then tbb socket, then env vars. But extra scripts are just trying the first socket.

evn vars should have priority over auto detection for sure. That's something the operating system or system administrator has set up and should be honored.

If I am not mistaken, command line parameters in the Linux world overwrite all. I.e. have priority over environment variables and configfuration files.

priority 1 = highest

1 command line parameters

2 env vars

3 config files

4 auto detection

priority 4 = lowest

I think.

nyxnor commented 2 years ago

priority 1 = highest

  • 1 command line parameters
  • 2 env vars
  • 3 config files
  • 4 auto detection

priority 4 = lowest

Done this locally.

  1. cli is priority n1.
  2. The problem I see is that env vars are just for TBB correct? So see why this is a problem in point 3
  3. Config files read are from the filesystem, especifically the tor daemon files that are more easily to locate than the TBB files.
  4. what I am doing locally is after failing 1,2,3, them try 127.0.0.1:9051 and if it fails try 127.0.0.1:9151.

So as you can see the separation:

  1. doesn't matter if it is daemon or browser
  2. always browser
  3. always daemon
  4. daemon socket then browser socket

So what I was thinking is trying every possibility on the daemon first then try TBB. Why? Even though it is not a standard priority, it will still be followed, but per tor system basis, and I feel this is more clean it trys daemon sockets first then TBB. Example:

  1. cli (tor daemon or TBB)
  2. file system (tor daemon)
  3. 127.0.0.1:9051 (tor daemon)
  4. env vars (TBB)
  5. 127.0.0.1:9151 (TBB)

If you don't agree, let me know, because the "correct" priority would mess with tor daemon and browser:

  1. cli (tor daemon or TBB)
  2. env vars (TBB)
  3. file system (tor daemon)
  4. 127.0.0.1:9051 (tor daemon)
  5. 127.0.0.1:9151 (TBB)
nyxnor commented 2 years ago

a1246bc

Chose per tor system, but this can be changed to standard priority if there is a better reason.

adrelanos commented 2 years ago

related: Maybe an easy option for users for the common case --tbb would help? (Useful for those who have TBB and system Tor installed.)

  1. The problem I see is that env vars are just for TBB correct?

No. All sorts of projects are now looking at these variables.

So what I was thinking is trying every possibility on the daemon first then try TBB.

Sounds good.

  1. cli (tor daemon or TBB)
  2. file system (tor daemon)
  3. 127.0.0.1:9051 (tor daemon)
  4. env vars (TBB)
  5. 127.0.0.1:9151 (TBB)

Probably good enough.

How to do it better? I don't know. Yeah. I can see now that there's quite some complexity here.

If you don't agree, let me know, because the "correct" priority would mess with tor daemon and browser:

  1. cli (tor daemon or TBB)
  2. env vars (TBB)
  3. file system (tor daemon)
  4. 127.0.0.1:9051 (tor daemon)
  5. 127.0.0.1:9151 (TBB)

Well, env vars would be good to have quite high priority. It's not just TBB. And a TBB installation doesn't set up system env vars. So if there's env vars you can be sure it was setup by distribution or system administrator.

nyxnor commented 2 years ago

Maybe an easy option for users for the common case --tbb would help?

Nice. It would be better to distinguish tor daemon from tor browser, was thinking about it also.

So the flow:

default to tor daemon

--tbb

Does this lookes better? Should I use env vars on tor daemon? I think not because people set them to 9151, not 9051.

nyxnor commented 2 years ago

it is working, if something is not expected, please reopen.

adrelanos commented 2 years ago

Should I use env vars on tor daemon? I think not because people set them to 9151, not 9051.

Some people use TBB with system Tor. Hence, the env var could very well be set to 9051. Also people use Tor running on another machine in the LAN.

it is working, if something is not expected, please reopen.

Off-topic: Btw that's not possible anymore on github. Reporter can no longer re-open.

nyxnor commented 2 years ago

Some people use TBB with system Tor. Hence, the env var could very well be set to 9051. Also people use Tor running on another machine in the LAN.

This issue is taking longer because it is a important decision of which socket to use, sorry to bother.

cli > env > filesystem > fallback

I don't like unexpected results, if not using machine mode, it is printing the command being run to what socket https://github.com/nyxnor/tor-ctrl/blob/a8d9bf3c244832e71b1a5f5c9c6ef698fd73ac68/usr/bin/tor-ctrl#L416

So it still leads, to enforce the socket you want, you need to specify with -s SOCKET, and the --tbb can or can not work.

I will let you close this time when you feel it is ready.

adrelanos commented 2 years ago

Some people use TBB with system Tor. Hence, the env var could very well be set to 9051. Also people use Tor running on another machine in the LAN.

This issue is taking longer because it is a important decision of which socket to use, sorry to bother.

cli > env > filesystem > fallback

That seems pretty much how most applications work on Linux.

  • If selecting --tbb and not specifying socket on the cli, but the env var is 9051, then it will use the daemon instead of tbb

Sounds good.

If selecting --tbb, env vars can be ignored. That could be done by changing the contents of these variables inside the script.

For example:

[ -n "$TOR_SOCKS_PORT" ] || TOR_SOCKS_PORT="9150"

If TOR_SOCKS_PORT is set already, leave it. Otherwise, set a reasonable default.

Then below that if --tbb is recognized by the script, set

TOR_SOCKS_PORT="9150"
  • if not selecting the above options, not specifying socket on the cli, but the env var is 9151, then it will use always the browser port instead of the daemon

Yes.

I don't like unexpected results, if not using machine mode, it is printing the command being run to what socket

That is very good for transparency/usability. If you'd like to go further, you could even explain why that is happening in the script output. A self-documenting script.

I will let you close this time when you feel it is ready.

Alright. Will test.

nyxnor commented 2 years ago

something still to do here?

nyxnor commented 2 years ago

something still to do here?

adrelanos commented 2 years ago

No.