[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: tor controlport wants authentication even if authentication is switched off

Thanks for your reply now I understand :) !

But this isn't explained in control-spec.txt. At least I hadn't understood it in that way. Maybe the specs could be updated to make this more clear? Of course 3.5 says "Before the client has authenticated..". But it feels more natural that when authentication is switched off that no authentication at all is needed, you know. I hadn't understood while reading the specs that even if authentication is switched off this AUTHENTICATE command is needed. Maybe after the syntax explaination could be written "The AUTHENTICATE command has to been sent in every case. Even if all authentication-methods are switched off it has to be sent to prevent some neat attacks against the TC.". Because as I read 3.5 an authentication failure is just reported if the cookie is incorrect and not that it is needed in any way.

Also the first sentence in 5.1 could maybe be more accurate with saying: "By default, the current Tor implementation trusts all local users." because it trusts just those users by default who authenticate.


  Sent from the client to the server.  The syntax is:
     "AUTHENTICATE" [ SP 1*HEXDIG / QuotedString ] CRLF

  The server responds with "250 OK" on success or "515 Bad authentication" if
  the authentication cookie is incorrect.  Tor closes the connection on an
  authentication failure.

  The format of the 'cookie' is implementation-dependent; see 5.1 below for
  information on how the standard Tor implementation handles it.

  Before the client has authenticated, no command other than PROTOCOLINFO,
  AUTHENTICATE, or QUIT is valid.  If the controller sends any other command,
  or sends a malformed command, or sends an unsuccessful AUTHENTICATE
  command, or sends PROTOCOLINFO more than once, Tor sends an error reply and
  closes the connection.

  (Versions of Tor before and did not close the
  connection after an authentication failure.)


5.1. Authentication

  By default, the current Tor implementation trusts all local users.  

  If the 'CookieAuthentication' option is true, Tor writes a "magic cookie"
  file named "control_auth_cookie" into its data directory.  To authenticate,
  the controller must send the contents of this file, encoded in hexadecimal.

  If the 'HashedControlPassword' option is set, it must contain the salted
  hash of a secret password.  The salted hash is computed according to the
  S2K algorithm in RFC 2440 (OpenPGP), and prefixed with the s2k specifier.
  This is then encoded in hexadecimal, prefixed by the indicator sequence
  "16:".  Thus, for example, the password 'foo' could encode to:
           salt                       hashed value
  You can generate the salt of a password by calling
           'tor --hash-password <password>'
  or by using the example code in the Python and Java controller libraries.
  To authenticate under this scheme, the controller sends Tor the original
  secret that was used to generate the password, either as a quoted string
  or encoded in hexadecimal.

kind regards

Attachment: signature.asc
Description: PGP signature