[tor-bugs] #28295 [Core Tor/Nyx]: Non-interactive way to supply ControlPort password for nyx and tor-prompt is needed

Tue Nov 6 16:49:54 UTC 2018

#28295: Non-interactive way to supply ControlPort password for nyx and tor-prompt
is needed
--------------------------+------------------------------
 Reporter:  wagon         |          Owner:  atagar
     Type:  enhancement   |         Status:  assigned
 Priority:  Medium        |      Milestone:
Component:  Core Tor/Nyx  |        Version:  Tor: 0.3.4.8
 Severity:  Normal        |     Resolution:
 Keywords:                |  Actual Points:
Parent ID:                |         Points:
 Reviewer:                |        Sponsor:
--------------------------+------------------------------

Comment (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
 [[https://gitweb.torproject.org/torspec.git/tree/control-spec.txt|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
 "[[https://gitweb.torproject.org/torspec.git/tree/control-
 spec.txt|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
 [[https://stem.torproject.org/_modules/stem/connection.html|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
 [[https://stem.torproject.org/faq.html#i-m-using-cookie-
 authentication|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.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/28295#comment:7>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online