I just realized that the way I phrased it was misleading.
It's not that I think TCP/IP is inherently secure. It's that, because TCP/IP is not inherently secure, I don't think raw TCP/IP addresses should be exposed to end-users. In other words, the right way to phrase it would have been.
> If you get the TOR address from a trusted source, like the Azure dashboard, then you’re connecting to the correct machine. No need to rely on people being meticulous enough to compare hex addresses.
> because TCP/IP is not inherently secure, I don't think raw TCP/IP addresses should be exposed to end-users
Right, that's why we have TLS.
Most network protocols these days use crypto, one way or another. Many use TLS, as it's generally the right answer. For better or worse, SSH does things its own way.
I have to admit I don't know much about Tor, but I don't see how it has much to offer here. The more relevant technology would be VPNs. Properly configured SSH is pretty solid on its own though, especially if combined with IP whitelisting to filter out port-scanners and help stop you getting in trouble if there's a zero-day against your SSH server software.
The advantage of Tor Hidden Services* is that it doesn't need DNS, and it doesn't need CAs.
The problem with DNS is that DNS names are global, and human readable, and therefore rely on a central authority to handle disputes. They aren't even particularly good at human-readability, because they have a vestigial hierarchy that doesn't even mean anything half the time, and they aren't given enough scrutiny to make sure that nobody uses confuseable, typo squatted, or bit squatted names.
The problem with CAs is that they're centralized, and they need to be able to see your domain name in order to validate it. This makes air gapped systems a pain in the neck, along with anything else that calls into question the global reach-ability assumption that they're making (like plain ol' networking glitches).
* The Tor network also has exit nodes that can access the regular web. For this to be secure, you need all of the normal security practices for websites, including TLS. Hidden Services don't need exit nodes, and they don't need TLS.
> The problem with DNS is that DNS names are global, and human readable, and therefore rely on a central authority to handle disputes.
This isn't a problem in practice. DNS security issues do exist, but typically don't relate to its centralisation.
That's not to say there are no downsides to centralisation. I'm not especially happy about the way everyone with a website has to pay money to rent-seekers. I'm also opposed to the unending addition of novelty TLDs, and to the way special domains like t.co are only available to organisations with unusual clout.
> They aren't even particularly good at human-readability, because they have a vestigial hierarchy that doesn't even mean anything half the time
I don't see a real problem here either.
> they aren't given enough scrutiny to make sure that nobody uses confuseable, typo squatted, or bit squatted names
The basic goal, roughly speaking, is to map from string to IP address, so the existence of confusingly similar strings is a problem sometimes, yes. Again I really don't know much about Tor - how does Tor solve this?
> they need to be able to see your domain name in order to validate it. This makes air gapped systems a pain in the neck
You're not the only one to say this, but I don't see the problem. You can get a cert for intranet.example.com, give it a 'parked' public-facing page, get a cert for it, then use that cert internally for your intranet. You could also get a wildcard cert. Seems like a pretty solid solution.
> along with anything else that calls into question the global reach-ability assumption that they're making (like plain ol' networking glitches)
I'm not sure I follow here, what do you mean? DNS is very robust.
> Hidden Services don't need exit nodes, and they don't need TLS.
I see. How can I trust the connection though? What's to stop an attacker taking control of my network connection and pointing me at their machine instead?
Doesn't there need to be some kind of secret-management system in place? SSH answers this with fingerprints. HTTPS answers it with certs and CAs.
It's not that I think TCP/IP is inherently secure. It's that, because TCP/IP is not inherently secure, I don't think raw TCP/IP addresses should be exposed to end-users. In other words, the right way to phrase it would have been.
> If you get the TOR address from a trusted source, like the Azure dashboard, then you’re connecting to the correct machine. No need to rely on people being meticulous enough to compare hex addresses.