Opened 13 days ago

Last modified 9 days ago

#28295 assigned enhancement

Non-interactive way to supply ControlPort password for nyx and tor-prompt is needed

Reported by: wagon Owned by: atagar
Priority: Medium Milestone:
Component: Core Tor/Nyx Version: Tor: 0.3.4.8
Severity: Normal Keywords:
Cc: Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

When Tor's ControlPort requires password authentication, nyx and tor-prompt ask it interactively. However, it must be also a way to specify the password in a command line or in config file. Earlier it was possible with arm's option startup.controlPassword, which no longer works with nyx.

Child Tickets

Change History (7)

comment:1 Changed 13 days ago by wagon

Type: defectenhancement

comment:2 Changed 13 days ago by arma

Cc: atagar removed
Component: ApplicationsCore Tor/Nyx
Reviewer: atagar

comment:3 Changed 13 days ago by wagon

Keywords: nyx removed

comment:4 Changed 12 days ago by atagar

Oh oops. Thanks wagon, this is a good point, I did forget the controller password from the config options. My bad.

From a technical standpoint I'm unsure it's useful, since a persisted config password is effectively cookie authentication. Said another way, in authentication schemes a password is 'something you know' whereas cookie auth is 'something you have'. If you write your password into a text file it's just a poor man's cookie authentication.

That said, this is likely to confuse others too so I should simply add it. Not sure when I'll get around to this (patches welcome), but I'll be sure it's included in the next release.

comment:5 Changed 11 days ago by wagon

From a technical standpoint I'm unsure it's useful, since a persisted config password is effectively cookie authentication. Said another way, in authentication schemes a password is 'something you know' whereas cookie auth is 'something you have'. If you write your password into a text file it's just a poor man's cookie authentication.

I would say the opposite: cookie authentication is a poor man's password authentication.

When you use cookie file (i.e. socket mechanism of communication between processes):

  1. You cannot use standard firewall tools to monitor access to this file and report all unauthenticated access attempts. You cannot later investigate possible incidents and get information: who (user), when (time), and why (malicious or not?) accessed Tor's ControlPort. Strictly speaking, it is still possible to monitor access with some non-standard sophisticated mechanisms, but I consider them to be more hard to learn and use (than firewall).
  2. By default (if you don't use ACL) you are restricted to standard UNIX mechanisms of access control for the cookie file. (For example, you cannot make a single file readable for one user group, but writable for another user group.) Though I cannot tell now some good example when this may be needed, potentially it may happen.

Thus, if you have a properly configured firewall, you get very powerful and flexible solution for both the access control and the monitoring.

However, despite you can configure such a firewall for your needs, there is no standard firewall tool for everybody which works out-of-the-box for most configurations. Without such firewall tool the password authentication doesn't give you more than cookie authentication. So, for layman Tor users, cookie authentication (now working in many systems) is a very simple but still sufficiently secure out-of-the-box solution. Using firewall and password authentication you can do the same and much more, but most of people either don't need it or don't have time and knowledge to configure it.

I'll be sure it's included in the next release

Good news! Thank you!

Last edited 11 days ago by wagon (previous) (diff)

comment:6 Changed 10 days ago by atagar

I would say the opposite: cookie authentication is a poor man's password authentication.

Your two points are true for ControlSockets, but a ControlPort with cookie authentication shouldn't differ from password authentication in this respect. In either case nyx is 'providing the contents of a file to tor's control port'. The only difference is that with password authetnication its your raw password, with cookie auth it's an autogenerated hash in a file with especially restricted permissions, and with SafeCookie it's a more complicated handshake that prevents replay attacks and such.

comment:7 Changed 9 days ago by wagon

Your two points are true for ControlSockets, but a ControlPort with cookie authentication shouldn't differ from password authentication in this respect. In either case nyx is 'providing the contents of a file to tor's control port'.

This was mind-blowing! Thank you for your comment. Actually, the situation is non-trivial, but let me start from the beginning.

The first point: why I was wrong. Let's look at man torrc:

CookieAuthentication 0|1

If this option is set to 1, allow connections on the control port when the connecting process knows the contents of a file named "control_auth_cookie", which Tor will create in its data directory. This authentication method should only be used on systems with good filesystem security. (Default: 0)

CookieAuthFile Path

If set, this option overrides the default location and file name for Tor’s cookie file. (See CookieAuthentication above.)

CookieAuthFileGroupReadable 0|1

If this option is set to 0, don’t allow the filesystem group to read the cookie file. If the option is set to 1, make the cookie file readable by the default GID. [Making the file readable by other groups is not yet implemented; let us know if you need this for some reason.] (Default: 0)

As you can see, man torrc makes a strong impression, that users which use cookie authentication, will always have to use the same CookieAuthFile as Tor uses (located in /var/run/tor by default)! Moreover, not only man page, but also all how-to and implementations (such as Nyx) also use that Tor's CookieAuthFile from that location. Since I thought this restriction exists, I wrote my point 2: we cannot make clever multi-user access to the same file. Only after your comment I understood that any ControlPort user can just copy that file from /var/run/tor to its own directory, which, indeed, makes cookie authentication to be functionally the same as the password authentication.

The second point. Nyx doesn't support cookie authentication too! Strictly speaking, it can read cookie file only from standard place in /var/run/tor. I cannot give to nyx some copy of CookieAuthFile (with the same content) located at another place. This has to be implemented in Nyx.

As I understand it, many applications (including Nyx) have to have some access also to other Tor files such as Tor logs and torrc. So, since these applications will access Tor's log and config files anyway, access to Tor's cookie file is nothing exceptional. That's why everywhere it is recommended to include your user to debian-tor group and to not complicate the things. Nevertheless, in some rare secure cases, some applications can be denied access to Tor files (though ControlPort still can be used by them).

The third point. We have 3 types of authentication: password, cookie, and safecookie. I'm not an expert, but at first glance, password authentication looks safer than cookie authentication, but weaker than safecookie authentication. Moreover, according to specs, cookie authentication is deprecated:

the COOKIE authentication method has been deprecated and will be removed from Tor before some future version of Tor.

Unfortunately, at the moment Tor doesn't allow us to disable standard cookie authentication (keeping only safecookie). Should we request some option in torrc for this task? Anyway, in future, we will have only safecookie and password authentications.

I tried to understand how to use safecookie, but was unable to figure out where I should take values for the "undefined variables" "Tor safe cookie authentication server-to-controller hash" and "Tor safe cookie authentication controller-to-server hash". Google tells that only two opensource applications use safecookie method, and one of them is your Stem. Thanks to your code I have understood the mystery: it is just literally the value of the constant. :)

Taking into account that it is not so well documented, not so many examples in Internet, and deprecation of standard cookie method, I would like to ask you to include safecookie telnet method to your page too: instead of the words

SAFECOOKIE authentication is a lot more involved, and not something you will want to do by hand (though Stem supports it transparently).

add a command-line how-to:

% CookieString="$(xxd -u -p -c32 < /var/run/tor/control.authcookie)"
% ClientNonce="$(xxd -u -p -l32 -c32 < /dev/urandom)"
% printf '%s\n' "${ClientNonce}"
9C653314CC4CC2C695999CE84EB1B0045E3D59B6AFFE615D624DB4870DD7041E
% telnet 127.0.0.1 9051
Trying 127.0.0.1...
Connected to 127.0.0.1.
Escape character is '^]'.
AUTHCHALLENGE SAFECOOKIE 9C653314CC4CC2C695999CE84EB1B0045E3D59B6AFFE615D624DB4870DD7041E
250 AUTHCHALLENGE SERVERHASH=16274D83FC2240DF9D50D74009D9AE107B77EA317F0034D3638C7942F350D1F9 
                  SERVERNONCE=1C2E73C41FA8537FDD3A59C2ECBE26DFC85E0A05389373AD8C130C0F5795A036
^]
telnet> z

[1]+  Stopped                 telnet 127.0.0.1 9051
% ServerNonce="1C2E73C41FA8537FDD3A59C2ECBE26DFC85E0A05389373AD8C130C0F5795A036"
% printf '%s%s%s\n' "${CookieString}" "${ClientNonce}" "${ServerNonce}" | xxd -r -p \
> | openssl dgst -sha256 -binary -hmac "Tor safe cookie authentication controller-to-server hash" \
> | xxd -p -u -c32
A733E09A65E2A6030BF6710D800370FC3AD28E1D2545E1692D160545D93CEE68
% fg
telnet 127.0.0.1 9051
AUTHENTICATE A733E09A65E2A6030BF6710D800370FC3AD28E1D2545E1692D160545D93CEE68
250 OK
GETINFO version
250-version=0.3.4.9 (git-074ca2e0054fded1)
250 OK
QUIT
250 closing connection
Connection closed by foreign host.

The fourth point. Firewall is a more reliable way to control authentication. If loopback interface is properly filtered, only selected user can send packets to 127.0.0.1:9051. In this sense, in secure setting, even completely disabled authentication is not critical.

Note: See TracTickets for help on using tickets.