Comment by nikcub | Hacker News Reader

Comment by nikcub | Hacker News Reader

If you are looking for a practical use of hidden services: we use them as ingress for Docker and K8 management.

You start a container that runs just tor with a config and can read the routing endpoints from your config, or link to localhost:2375

HiddenServicePort <onion port> <host>:<port>

You setup HiddenServiceAuthorizeClient with stealth auth type and a list of authorized clients.

You can lock your firewall rules down as the hidden service only requires outbound to HTTPS.

On the client end you setup regular Tor with HidServAuth <onion address> <auth-cookie>

With stealth auth other tor users won't see the serivce and port published without the auth cookie

You can then use socat to bind the remote hidden service and port to a local host and port:

socat tcp-l:127.0.0.1:2023,fork socks4a:onionaddr.onion:localhost:23,proxyport=9050

You then have the remote ssh server available locally with no public interfaces, no public ports, and an additional layer of confidentiality and authentication

Apparently you need to stick to the second version of hidden services if you want to use stealth authentication.

Just tried to upgrade and got this `[warn] Hidden service option HiddenServiceAuthorizeClient is incompatible with version 3 of service in <path>`.

Does anyone know if there is any plan to support stealth authentication? It's a pretty usefull feature.

Awesome, this is what I had in mind for using a stealth way to manage infrastructure. Thanks for sharing a blueprint as I'd only theorycrafted it and now I have a path to experiment with.

It's also great as a secure and anonymous alternative to something like noip.

Yes, this is exactly the same way I've been using hidden services for some time. It started as a "stealth gateway" for some of my personal services (e.g. VPN, file server, etc), and grew into something like what you're describing for managing infrastructure. I'm glad to see others doing the same thing. Thanks for sharing!

> additional layer of confidentiality and authentication

and additional layers of attack surfaces

From a IT Security Assessment, what would those be and their associated risk and impact factors?

One would naturally be the onion address. If they could break the 1024 bit RSA key, they could hijack the name. Risk of this happening: very low. Impact: massive especially outside the realm of tor.

Any additional risks you were thinking about? Backdoors in tor project? Hardware malware specifically designed for tor (rather than than being general)?

I believe the main concern would be vulnerabilities in the Tor software itself.

That said, I don't think there's any reason to believe Tor is any more likely to be vulnerable than any other software in your stack. The project is open source, and is very much written with a focus on security and privacy.

This sounds cool, but it's needlessly complicated. Why not simply configure SSH to use multiple forms of authentication [1]: password + public key auth + 2FA (Duo Security, Google Authenticator, Authy, etc.). That's all you need to achieve a very secure state.

1 https://wiki.mozilla.org/Security/Guidelines/OpenSSH#Multi-F...

Reply on news.ycombinator.com