Comment by notriddle | Hacker News Reader

Comment by notriddle | Hacker News Reader

Parent Full thread

SSH's model isn't very good, either. You can be MITM'ed for free the first time you connect (obviously, that's what TOFU means), and server identities are tied either to network addresses or to domain names, neither of which are permanent.

Tor Hidden Services are closer to a well-designed petname system. The important insight is that, since domain names are too technical for ordinary people anyway, they might as well just be random numbers. If you trust someone to give you the real domain name for the server, you can also trust them to give you a signature for their real public key, and you don't even need a CA any more. The advantage of using a cryptographic signature for your address is that it implicitly forms a web of trust, using the links that people were already sharing.

The biggest problem with this — and SSH doesn't seem to do a better job of it than Tor does — is key rotation. Deprecating an old cryptographic algorithm is a total disaster in any system that doesn't support key rotation — it's fine on the server side (just host with both keys, and serve a 301 redirect from the old one to the new one), but the client side eventually needs to stop supporting the old algo, because those would be vulnerable to downgrade attacks, and at that point you cut off anyone who hasn't switched to the new one yet. CA's take care of this, because it's literally their job, but distributing the responsibility to everyone can easily mean it doesn't get taken care of properly.

> SSH's model isn't very good, either. You can be MITM'ed for free the first time you connect

This is how many people seem to use SSH, yes. It's also quite plainly the wrong way. I'm thankful the people behind HTTPS have higher standards than the typical Unix user seems to have.

I've mentioned before on HN that I once submitted a ServerFault question after finding myself unable to match the SSH fingerprint shown on the EC2 web interface against the one PuTTY was showing. [0][1] It turned out that PuTTY's fingerprint scheme was MD5/hex, whereas OpenSSH had switched to SHA256/Base64. I was surprised no one else had asked the question.

I dabbled with Azure recently, and iirc it was close to impossible to view the SSH fingerprint of a new instance using their web interface. Perhaps it was possible via a web-based command-line session. Either way it was disappointing.

I now suspect I'm part of a tiny minority of people who ever think to check SSH fingerprints.

> You can be MITM'ed for free the first time you connect (obviously, that's what TOFU means)

Judging by the old thread [0], at least one person uses it to mean Check manually on first use then trust it, rather than to mean Blindly trust on first use. Wikipedia seems to agree that the term can refer to either strategy. [2] I now make a point to say blindly trust on first use, or check manually on first use, to disambiguate.

Also, for what it's worth, SSH certificates do apparently exist, [0] but I know nothing about them.

[0] https://news.ycombinator.com/item?id=23958456

[1] https://serverfault.com/questions/996828/

[2] https://en.wikipedia.org/wiki/Trust_on_first_use

That’s true, but I guess my point is that Hidden Service addresses are harder to misuse. If you get the 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.

> If you get the 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.

No, that's wrong. That's my point. If TCP/IP were inherently secure we wouldn't need SSH in the first place.

SSH fingerprints offer you the opportunity to cryptographically verify that you're connecting to the machine you think you're connecting to. If you fail to check the fingerprint, and instead blindly assume it's ok, you could be connecting to an attacker's machine instead.

This turned up in the previous thread too. https://news.ycombinator.com/item?id=23960905

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.

Reply on news.ycombinator.com