SSH does in fact have a PKI, just not a global one. Large-fleet SSH installs all tend to use certificate authorities, for this reason (and to simplify SSO).
I understand that most people don't use it and indeed rely on tofu, but the statement is not absolutely correct.
ssh server keys can be authenticated using (the DNSSEC "CA" system and) SSHFP, and it's possible to setup a signing CA for the host key (similar to ssh certificates, however not applicable for foreign servers).
And of course, the fingerprint could be advertised out of band e.g. on the homepage with tls
sshfp is not PKI. It's an option and it is off by default in ssh(1). In practice no one actually deploys it, exe.dev, terminal.shop, jobs.{whoever.com}, etc. I've yet to see an in the wild deployment. The aforementioned sites let you perform electronic payment transactions over ssh without it, which is probably a PCI violation tbh, but auditors aren't good enough.
Agreed. Amid all this hype, once again we continue to see such disregard for basic security implications and using ssh outside it's intended use-case; especially sshing into random servers.
Now we wait for the discovery of an RCE, key leakage vulnerability or a security bypass that leads to a trivial mitm attack to magnify why ssh apps make no sense security wise.
SSH does in fact have a PKI, just not a global one. Large-fleet SSH installs all tend to use certificate authorities, for this reason (and to simplify SSO).
Acronyms are supposed to be capitalised. I do not belive you are talking about the soy product.
https://en.wikipedia.org/wiki/Man-in-the-middle_attack
https://en.wikipedia.org/wiki/Trust_on_first_use
I understand that most people don't use it and indeed rely on tofu, but the statement is not absolutely correct.
ssh server keys can be authenticated using (the DNSSEC "CA" system and) SSHFP, and it's possible to setup a signing CA for the host key (similar to ssh certificates, however not applicable for foreign servers). And of course, the fingerprint could be advertised out of band e.g. on the homepage with tls
sshfp is not PKI. It's an option and it is off by default in ssh(1). In practice no one actually deploys it, exe.dev, terminal.shop, jobs.{whoever.com}, etc. I've yet to see an in the wild deployment. The aforementioned sites let you perform electronic payment transactions over ssh without it, which is probably a PCI violation tbh, but auditors aren't good enough.
webpki is on by default.
Yes, but what exactly would an attacker achieve by doing mitm here?
here, less than most, but look for ssh agents
on terminal.shop, steal credit cards on jobs endpoints, perform identity theft on exe.dev, whatever you put on there
Agreed. Amid all this hype, once again we continue to see such disregard for basic security implications and using ssh outside it's intended use-case; especially sshing into random servers.
Now we wait for the discovery of an RCE, key leakage vulnerability or a security bypass that leads to a trivial mitm attack to magnify why ssh apps make no sense security wise.