Comment by raggi
So approximately nothing?
So approximately nothing?
I don't know what other solutions there are to TOFU, but maybe it's nice if there's something like a standardised /.well-known/ssh-keys.json path for public ssh servers like github and pico.sh.
There’s SSHFP, but it’s off by default and assumes an attacker can’t modify dns, though most mitms would be executed with dns and dnssec deployment is generally a disaster.
Currently their host key page is only linked once at the bottom of their page and isn’t referenced in any onboarding docs, so effectively onboarding encourages “yolo”, and if users aren’t savvy they’re likely putting other things at risk, whatever their keys happen to also have access to.
The other argument that comes up here then is “well mitms are rare so this doesn’t seem like a big problem in practice”, however there are actually great targets here, for example you go to a conference and hijack the WiFi, then spend your time in hallway track advertising these services to your targets. This kind of thing has a high success rate.
The web improves on this problem with PKI, though similar phishing tactics exist in a similar situation where you encourage people to sign up explicitly guiding them to an incorrect domain, but propensity for using search in address bars strongly helps resist this too.
SSH is terrible for this use case, no matter how it makes people feel.
Perhaps giving a bit more information than throwing out random acronyms related to SSH would be a bit more fruitful in terms of responses.
What about TOFU and MITM would you like them to respond to? TOFU isn't inherently a bad thing. Neither is MITM. It depends on the threat model, the actors involved, etc.
Your comment (and the snarky followup) imply they're doing something wrong, but it's unclear what.