Control port failures for hidden services
With Tor 0.3.2.9 on Linux, connect to the control port. Then setconf HiddenServiceDir (to create a new service) and HiddenServicePort, as one command. Then getconf HiddenServiceOptions to make sure it's right.
Now, connect to your new hidden service from another computer, with no authorization. Success, as expected.
Then, setconf HiddenServiceDir (for the same service as before), HiddenServicePort, and HiddenServiceAuthorizeClient, all as one command. Notice the hostname file for the hidden service now contains an auth cookie, as expected.
Finally, connect to the hidden service again from another computer, still with no authorization. Success! But it should fail, since you didn't provide the auth cookie!
To fix it, you have to restart Tor on your server, and do setconf with HiddenServiceAuthorizeClient the first time.
The same bug hits in the other direction too: after you restart Tor to start enforcing the auth cookie, if you do setconf without HiddenServiceAuthorizeClient, then the auth cookie immediately disappears from the hostname file (as expected), but Tor continues enforcing the cookie until you restart.
The same configuration-stickiness bug applies to setconf HidServAuth on the client side too (tested on Linux and Windows). If you try to connect to a hidden service requiring authentication before you set HidServAuth, then of course it fails, but if you then set HidServAuth, it still fails. You have to restart Tor, then set HidServAuth before you try to connect to the hidden service for the first time. Then it will succeed.
Just to be clear: to trigger these bugs, do all the various configurations and reconfigurations exclusively via the control port. Don't set any of them in torrc.
Trac:
Username: oqista