3 ms·

It's really ridiculous that ssh does not use standard PKI which is deployed everywhere. So unsecure.

dspillett 1y ago
To use the style of server identity management we use for, say, HTTPS, you need a “trusted” 3rd party involved to sign certificates. This is impractical for SSH in many (most?) cases for several reasons (SSH does support cert based identification and authentication, but there are not many circumstances where this is more practical than, or otherwise preferable to, TOFU for SSH). In fact, many people who don't properly understand SSH's trust-on-first-use system (so don't actually verify server certificate fingerprints) argue for browsers to support it as an option alongside the current certificate signing & verification regimes.
kragen 1y ago
By "standard PKI which is deployed everywhere" do you mean SSL certificates? That would make you vulnerable to dozens of poorly secured CAs throughout the world; any attacker who could penetrate one of them could then use that access to MITM any SSH connection in the world (if they could additionally spoof DNS). SSL certificates are probably the best we can do for the "talk to a server you've never heard of" scenario, but we can do enormously better for the scenario where you're SSHing into a server you already have a pre-existing trust relationship with.
- vbezhenar 1y ago
  It is good enough for websites, it will be good enough for ssh. "pre-existing trust relationship" prevents from rotation keys which is standard security measure (unheard of in ssh, of course).
  - kbolino 1y ago
    Let us set aside the reasons why SSH adopted a different certificate format (namely, that X.509 is much more complex than they needed at the time). WebPKI only realistically serves a small portion of the SSH hosts out there. This is quite different from the situation with HTTPS. Even so, this would still be very convenient and useful. As I said elsewhere, I think this is sub-5% of SSH servers. X.509 more broadly could replace SSH certificates. Many institutional settings already have trust stores set up to include their in-house CAs. Public clouds and major hosting providers could also set up their own CAs, but they would have trouble distributing them (cf. AWS RDS, for example). Now we're probably up to 25% or so of deployed SSH servers. In the case of clouds, though, this adds a massive new exploitation vector (IP reassignment) and thus puts pressure on expiration/revocation. The rest are going to need self-signed certs. Between the non-WebPKI CA distribution problem and the probable predominance of self-signed certs, trust-on-first-use would still be the norm, and so relying on pre-existing trust relationships would still be necessary. We could augment TOFU/known-hosts with some kind of certificate or CA pinning rather than just key pinning, though. So, again, while I think adopting X.509 isn't a bad idea, and makes a lot more sense today than it did in 2010 (pre-Heartbleed!) when SSH added certificates, it's not really solving the problem that SSH has much better than today's solutions, no matter how well it solves the problem that HTTPS has.
  - kragen 1y ago
    > It is good enough for websites, it will be good enough for ssh. This is backwards. Breaking SSH authentication permits subverting most websites; the converse is not true. > "pre-existing trust relationship" prevents from rotation keys This is also false. Things like Signal and OTR rotate keys frequently and automatically within pre-existing trust relationships.
advisedwang 1y ago
ssh does support certificate based authentication [1] [1] https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/6/html/deployment_guide/sec-using_openssh_certificate_authentication https://docs.redhat.com/en/documentation/red_hat_enterprise_...
- vbezhenar 1y ago
  You can't just use letsencrypt certificates and make it work out of the box. Still insecure.
- jon-wood 1y ago
  Worth noting this is similar to but not the same as the type of certificate based authentication used in web browsers. Most notably you can't chain CAs, so there is no root of trust beyond whoever operates the CA you care about telling you the public key out of band. For SSH this is fine, because very rarely is anyone connecting to a random SSH server on the internet without being able to talk to the operators (hi Github, we see you there, being the exception).
kbolino 1y ago
The CA/Browser Forum does not want to support this either. They are only interested in public, domain-verified websites served over HTTPS. They forbid client certificates and dual-use CAs, they require certificate transparency and short expiration times, and their policies get stricter every year. Most SSH deployments would not want to accept these constraints. So, even if SSH supported X.509 certificates, which isn't necessarily a bad idea, it would be completely detached from WebPKI, thus removing most of the benefit.
- vbezhenar 1y ago
  A lot of servers do have domains associated with them. So that's not an issue. There are CA which will issue certificates for public IP addresses. So any public ssh server also can use these certificates. There's no reason to detach ssh PKI from Web PKI. They can use exactly the same certificates and keys.
  - kbolino 1y ago
    There is no doubt some number of SSH servers which have public domain names and/or public IP addresses, can accept DNS verification or running a completely unrelated HTTP server for IP verification, don't mind having their existence published in certificate transparency logs, don't care about or can separately handle client certs, and don't mind the SSH server restarting every ~month (until this gets shortened again) when the certificate is rotated. However, I would estimate the share of such sites at less than 5% of deployed SSH servers. The primary use case I can see here is to reuse an existing HTTPS cert for SSH on a box that already hosts a website. FWIW, there is an RFC for X.509 certificates in SSH, but it has not achieved wide adoption: https://www.rfc-editor.org/rfc/rfc6187 https://www.rfc-editor.org/rfc/rfc6187
    - kbolino 1y ago
      (I have also responded to you in kragen's subthread, you may want to consolidate the discussion there)
    - vbezhenar 1y ago

To use the style of server identity management we use for, say, HTTPS, you need a “trusted” 3rd party involved to sign certificates. This is impractical for SSH in many (most?) cases for several reasons (SSH does support cert based identification and authentication, but there are not many circumstances where this is more practical than, or otherwise preferable to, TOFU for SSH). In fact, many people who don't properly understand SSH's trust-on-first-use system (so don't actually verify server certificate fingerprints) argue for browsers to support it as an option alongside the current certificate signing & verification regimes.

kragen 1y ago

By "standard PKI which is deployed everywhere" do you mean SSL certificates? That would make you vulnerable to dozens of poorly secured CAs throughout the world; any attacker who could penetrate one of them could then use that access to MITM any SSH connection in the world (if they could additionally spoof DNS). SSL certificates are probably the best we can do for the "talk to a server you've never heard of" scenario, but we can do enormously better for the scenario where you're SSHing into a server you already have a pre-existing trust relationship with.

vbezhenar 1y ago
It is good enough for websites, it will be good enough for ssh. "pre-existing trust relationship" prevents from rotation keys which is standard security measure (unheard of in ssh, of course).
- kbolino 1y ago
  Let us set aside the reasons why SSH adopted a different certificate format (namely, that X.509 is much more complex than they needed at the time). WebPKI only realistically serves a small portion of the SSH hosts out there. This is quite different from the situation with HTTPS. Even so, this would still be very convenient and useful. As I said elsewhere, I think this is sub-5% of SSH servers. X.509 more broadly could replace SSH certificates. Many institutional settings already have trust stores set up to include their in-house CAs. Public clouds and major hosting providers could also set up their own CAs, but they would have trouble distributing them (cf. AWS RDS, for example). Now we're probably up to 25% or so of deployed SSH servers. In the case of clouds, though, this adds a massive new exploitation vector (IP reassignment) and thus puts pressure on expiration/revocation. The rest are going to need self-signed certs. Between the non-WebPKI CA distribution problem and the probable predominance of self-signed certs, trust-on-first-use would still be the norm, and so relying on pre-existing trust relationships would still be necessary. We could augment TOFU/known-hosts with some kind of certificate or CA pinning rather than just key pinning, though. So, again, while I think adopting X.509 isn't a bad idea, and makes a lot more sense today than it did in 2010 (pre-Heartbleed!) when SSH added certificates, it's not really solving the problem that SSH has much better than today's solutions, no matter how well it solves the problem that HTTPS has.
- kragen 1y ago
  > It is good enough for websites, it will be good enough for ssh. This is backwards. Breaking SSH authentication permits subverting most websites; the converse is not true. > "pre-existing trust relationship" prevents from rotation keys This is also false. Things like Signal and OTR rotate keys frequently and automatically within pre-existing trust relationships.

advisedwang 1y ago

ssh does support certificate based authentication [1] [1] https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/6/html/deployment_guide/sec-using_openssh_certificate_authentication https://docs.redhat.com/en/documentation/red_hat_enterprise_...

vbezhenar 1y ago
You can't just use letsencrypt certificates and make it work out of the box. Still insecure.
jon-wood 1y ago
Worth noting this is similar to but not the same as the type of certificate based authentication used in web browsers. Most notably you can't chain CAs, so there is no root of trust beyond whoever operates the CA you care about telling you the public key out of band. For SSH this is fine, because very rarely is anyone connecting to a random SSH server on the internet without being able to talk to the operators (hi Github, we see you there, being the exception).

kbolino 1y ago

The CA/Browser Forum does not want to support this either. They are only interested in public, domain-verified websites served over HTTPS. They forbid client certificates and dual-use CAs, they require certificate transparency and short expiration times, and their policies get stricter every year. Most SSH deployments would not want to accept these constraints. So, even if SSH supported X.509 certificates, which isn't necessarily a bad idea, it would be completely detached from WebPKI, thus removing most of the benefit.

vbezhenar 1y ago
A lot of servers do have domains associated with them. So that's not an issue. There are CA which will issue certificates for public IP addresses. So any public ssh server also can use these certificates. There's no reason to detach ssh PKI from Web PKI. They can use exactly the same certificates and keys.
- kbolino 1y ago
  There is no doubt some number of SSH servers which have public domain names and/or public IP addresses, can accept DNS verification or running a completely unrelated HTTP server for IP verification, don't mind having their existence published in certificate transparency logs, don't care about or can separately handle client certs, and don't mind the SSH server restarting every ~month (until this gets shortened again) when the certificate is rotated. However, I would estimate the share of such sites at less than 5% of deployed SSH servers. The primary use case I can see here is to reuse an existing HTTPS cert for SSH on a box that already hosts a website. FWIW, there is an RFC for X.509 certificates in SSH, but it has not achieved wide adoption: https://www.rfc-editor.org/rfc/rfc6187 https://www.rfc-editor.org/rfc/rfc6187
  - kbolino 1y ago
    (I have also responded to you in kragen's subthread, you may want to consolidate the discussion there)
  - vbezhenar 1y ago