5 ms·
I've been coming around to the idea that the threat models that are often used for website identity are not the ones we want. The ssh threat model related to ch
by tgbugs 5y ago
I've been coming around to the idea that the threat models that are often used for website identity are not the ones we want. The ssh threat model related to changes in host keys seems to me to be a better one.
The first time you connect to a website you get whatever identity it wants to show you. Whether it is a real site or not doesn't particularly matter, it only matters when the identity changes. If my first access was MITMed and then I connect to the "real" site, I should go and check to see what information changed, and if I sent any sensitive information I should probably do something to mitigate that (the exact action would depend on the exact type of info you sent). In the reverse case where you trust the original identity more than a changed identity you would ignore the event and might possibly want to inform the original entity that someone is trying to impersonate them.
Still fairly complicated for the original user, but certificate expiration would no longer be the insanity that it is now, and you can at least get transport security without the big scary self signed warnings that show up now.
- notriddle 5y agoSSH'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.
- MaxBarraclough 5y ago> 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 https://news.ycombinator.com/item?id=23958456 [1] https://serverfault.com/questions/996828/ https://serverfault.com/questions/996828/ [2] https://en.wikipedia.org/wiki/Trust_on_first_use https://en.wikipedia.org/wiki/Trust_on_first_use
- notriddle 5y agoThat’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.
- MaxBarraclough 5y ago> 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 https://news.ycombinator.com/item?id=23960905