Add HiddenServiceAuthorizeClient for an extra protection

[alnsn]

See http://nurdletech.com/linux-notes/ssh/hidden-service.html or the official tor documentation.

[fabacab]

A PR for this is open as #48.

[jchevali]

If in the context of strengthening SSH you add this extra protection, it will negate the need to have strengthened SSH in the first place. With this extra protection in place, you only need Telnet(d) on your server. Too much perfectionism, and the whole thing becomes undone at the seams.

[fabacab]

If in the context of strengthening SSH you add this extra protection, it will negate the need to have strengthened SSH in the first place. With this extra protection in place, you only need Telnet(d) on your server. Too much perfectionism, and the whole thing becomes undone at the seams.

I guess that depends on whether or not one considers "an adversary can discover that I am running an SSH server in the first place" to be part of "strengthening SSH" or not. Given that host discovery and enumeration is already a formalized practice of penetration testing, it seems reasonable to me that protecting the knowledge of the existence of a service, not merely the services's server configuration, should be considered a way to further strengthen the security of that service. ¯\_(ツ)_/¯

See also: "Defense in depth."

[jchevali]

Since the general release of Tor HS v.3 without client authorization, eliciting this new piece of advice implies recommending users stick with HS v.2, with weaker crypto and many years old.

[fabacab]

Interesting assertion. Can you point me at a source? I'd love to learn more about the differences about v3 versus v2 Onion services.

Specifically, I am unaware of Tor removing support for client authorization on v3 Onion services. Now that v3 Onion services are supported, if one is running a modern Tor (as one should be), then adding HiddenServiceVersion 3 to the linked pull request seems prudent, but the manual says nothing about v3 HS protocols not supporting stealth Onions. That's why I'd like to see where you're getting your information from. Thanks!

[jchevali]

HS v3 onions are stealth by default. They don't become stealth by virtue of issuing a HiddenServiceAuthorizeClient directive, like v2 onions; that at this point isn't even possible. Also, v3 onions aren't discoverable by malicious HSDirs as v2 onions were (a problem, I think, which affected v2 basic as well as stealth-type services). And they're harder to guess, as the names are longer.

However, if the event they could be leaked (e.g., by humans or a poorly-written script / bad client implementation), there's nothing to protect them, because you can't set up passwords for them - at least not till HiddenServiceAuthorizeClient is implemented.

If they are leaked, or you suspect that because you notice access patterns not matching your own, the best way to stop that would be recreating the service. Just stop it and erase the HS keys and when you restart it they'll be regenerated and started with a new hostname.

[jchevali]

https://trac.torproject.org/projects/tor/ticket/20700

[jchevali]

torproject/tor@f76f873