tor-ctrl - Tor control port command line tool

Development
36

tor-ctrl should probably have an onion-grater profile if anyone wants to create services from the Workstation.
Different than onionshare, target ports are not limited, so don’t know how to limit the profile with this.

I don’t have any reason to limit target port, it is ok for onionshare as it is designed around a one click installation and the server is configured for you. But for tor-ctrl, you probably will configure your server and you need to specify the target address that will be listened to by the webserver.

1 Like
37

A general tor-ctrl profile would be difficult. In that case, one could also set onion-grater to complain mode which lets through everything.

I don’t see the use case yet. Adding onion services isn’t a frequent task?
Anyhow. This would be contributions welcome. Not trivial to implement but easy on my side, it 1 more example profile in the onion-grater-merger examples folder.

38

Created an empty tor-ctrl-observer - Tor Connection Destination Viewer just now. (The page name can certainly be modified/moved if there are better suggestions.)

1 Like
39

I was looking tor command line tools and found carml.
It is very nice the monitor command, the log messages are easy to read not raw, even though you can still see raw with events command.
Carml is built upon txtorcon, both by Meejah.

Unfortunately carml does not have a debian package, but txtorcon the library has, so possible that in the feature he provides pushes it to debian.org.

interesting commands:

  • monitor → beautify events
  • onion → create onion services
  • newid → newnym
  • cmd → any controller command

Thoughts:

Much better than tor-ctrl of course in terms of user friendliness, interpreting events, has a whole library.
Not available on deb.debian.org so one would need to maintain the package. Has some dependencies not available on debian repos such as ansicolors.

It is a great tool and I hope it becomes available on debian soon, but it it on version 21.1.0, so maybe there is something blocking.

Docs

https://carml.readthedocs.io/en/latest/

1 Like
40
1 Like
41

tor-control-observe documentation written:

(The thumbnail is outdated, cached by this forum.)

If some screenshots / thumbnail / project logo was freely available, I’d add it to the wiki page.

42

issues corrected.

about the logo, I am not proficient in arts.

In the whonix usage page

**3.** Terminate `tor-ctrl-observe` with signal sigint.

Press keyboard keys `Ctrl` + `C`.

Ctrl+C will not terminate the whole script, just listening the stream, and then a summary will be shown.

1 Like
43

For me, if I press Ctrl+C during tor-control-observe, I get the summary and the script terminates. Bug?

44

For me, if I press Ctrl+C during tor-control-observe, I get the summary and the script terminates.

That is expected when calling from the command line.
The problem is when using the Desktop file, when using Ctrl+C, it will kill the terminal emulator.

The Ctrl+D option mentioned on gh seems to be posible and plausible.

1 Like
45

Yes, the signals can be “shuffled” to what makes most sense / easiest to use for the user. Usage of signals could be documented by adding a short console output message at script startup.

That seems like a good solution.

46

seeing again, eof (^D) is not a trap action, so it cannot execute another thing after being called, it will simply ignore or not ignore eof.

But QUIT is an action (^), altough kind weird, it works the Ctrl+\ (backslash).
The commands can be found with stty -a.

In this way I am thinking that ^C INT should interrupt the script and print summary and ^\ QUIT should quit the script immediately.

1 Like
47

I guess any keys are OK as long as the program says so. Bonus points for following standards / conventions as much as possible.

derivative-maker (previously Whonix build script) taps ctrl + c (sigterm) and shows a custom error handler once pressed. Does not necessarily end the script. One could even have a sigterm trap and do nothing, whatever that would be useful for.

1 Like
48

I am thinking of including SOURCE_ADDR, docs, to tor-ctrl.

It seems useful as it can indicate the client that sent the connection.
If the client is using the GW as the proxy vm, then it will show the correct WS IP assigned to the qube. e.g. 10.137.0.15 or another IP is not qubes.

But if the client is just using the GW as proxy to update on the template, then it will show a connection to localhost. e.g. 127.0.0.1:5999. The port is random.

How can I know the original IP, the qube ip for example, that requested the proxy on port 8082? Is it possible?

I am thinking of a way to identify which was the client that made the call to the proxy, because if someone is updating a bunch of vms together, then it will get difficult to know which one did a shady request to some domain. Of course qubes update tool runs one at a time, but any way…

Also, I think this is a great addition because maybe I could put an option to only show streams of a certain source_addr, for example: if multiple WS are connected to the same GW, then we can run tor-ctrl on 2 terminals and filter by connections made by the WS qube ip, this way it is easier to distinguish where may be some leaks.

What do you think?

1 Like
49

Dropped the qubes update proxy firewall thinkering, not possible to filter and is an upstream issue.

@adrelanos Should tor-ctrl-observer have a SOURCE_ADDR field? Do you think this would leak information of the client IP if the gateway is in a remote location?

For GW and WS on the same machine or LAN this is not a problem, only for remote GW.

1 Like
50

Seems highly useful.

I don’t know. Perhaps best to ask a Whonix-unspecified question at Qubes?

Yes, awesome idea!

Awesome!

Maybe document this risk at tor-ctrl-observer startup?
Perhaps two different start menu entries?

User has to take care of not posting unredacted tor-ctrl-observer logs anyhow in public since these reveal user activity. Some warning(s) would be nice.

51

Did that on How to identify which template requested to use the update proxy? - User Support - Qubes OS Forum
At the time of the writing above, I did not understand it was upstream issue.

This does not filter for update proxy, was related above, it is very difficult to know because it first uses 127.0.0.1 for DNS requests and then GW qube ip to CONNECT. So this is not very clean and for now there is only the option to specify one client ip to filter.

tor-ctrl-stream now has the option to specify client ip. Didn’t implement on -observer yet.
Thinking about it, if someone knows how to setup a remote tor gateway, they probably have some abilities, but yes, mistakes can occurr when posting logs.
I can do warnings anyway.

1 Like
52

If I make a debian build dir for GitHub - meejah/carml: Command-line utility to control Tor., use gpg to verify upstream git tag, would you be willing to substitue tor-ctrl for that?

tor-ctrl-observer with carml is much better: $ carml monitor --no-circuits --no-guards.
It prints exit nodes, but we can contribute upstream to add an option to hide that or even use grep -v ourselves.

1 Like
53
1 Like
54

I see some commits on History for usr/libexec/anon-gw-anonymizer-config/torrc-parser - Whonix/anon-gw-anonymizer-config · GitHub

Should I drop improvements of it on onionwash/onion-parser at master · nyxnor/onionwash · GitHub
?

onion-parser takes longer

real	0m1.217s
user	0m0.434s
sys     0m0.637s

than anon-verify

real	0m0.118s
user	0m0.064s
sys	    0m0.026s

It takes longer to parse but it does the job correctly, it includes all files parsed and prints correctly the extraneous files.

Would you rather use the anon-gw-anonymizer-config repo?

Why was this service removed?

Done this already, seems like the work is overlapping.

s’ >> ’ | tee -a 'g ------ doing this now

1 Like
55

I forgot about this code duplication. Ideally, onion-parser would be upstreamed. Meaning, anon-gw-anonymizer (which ideally wouldn’t need to exist) shouldn’t have it. If it can be upstreamed to onionwash, that would be good. PR welcome.

Actually better if upstreamed (to onionwash).

That included anon-verify.

Because now using %include /etc/torrc.d/*.conf. Fortunately, Tor has now wildcard (*) support. Hence, extraneous files such as these back editors (ending with ~) or those by dpkg (.dpkg-old) are now ignored by Tor. (If using the wildcard support which is very, very much recommended.)

Therefore fortunately any hacks to find and remove extraneous files can now be removed. The reason this was implemented was only as a stopgap because at the time Tor did’t have wildcard config parsing support.

This was added to ease debugging because the actual fix was quite difficult to figure out and took me a long time.

I prefer tee because than the xtrace (debugging output) (set -x or bash -x) is more self-explanatory.

Maybe in this case it’s better to revert the use of tee due to the slowdown?