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.
3.5. 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 0.1.2.16 and 0.2.0.4-alpha 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:
16:660537E3E1CD49996044A3BF558097A981F539FEA2F9DA662B4626C1C2
++++++++++++++++**^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
salt hashed value
indicator
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