4 ms·

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 ce

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
    More interesting statistics question is: how many connections over the world are opened to the servers with and without public domain/IP? I think that github alone makes a sizeable chunk of these connections. So if there was some better mechanism to establish trust before first handshake, that would benefit all of these connections. One approach that I could envision is to simply host ssh public key on some well known path (github.com/.well-known/ssh.pub) and ssh client will grab it over https before first connection and when key suddenly changes.
    - deleted 1y ago
      [deleted]
    - kbolino 1y ago
      I think your proposed solution is a great idea, but we're evaluating it at the wrong layer of the software stack. The real problem is Git(Hub)'s (mis-)use of SSH, not SSH itself per se. Adding full TLS and HTTP stacks to SSH clients would be massive bloat and a security/maintenance burden that OpenSSH, PuTTY, etc. probably don't want to take on. Whereas, it would be much easier for Git to add this functionality to its client, since it already has HTTPS support. I think we could also attack this problem from the angle of phasing out git+ssh protocol (or at least greatly reducing its use) by improving unattended/headless HTTPS user authentication.

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
  More interesting statistics question is: how many connections over the world are opened to the servers with and without public domain/IP? I think that github alone makes a sizeable chunk of these connections. So if there was some better mechanism to establish trust before first handshake, that would benefit all of these connections. One approach that I could envision is to simply host ssh public key on some well known path (github.com/.well-known/ssh.pub) and ssh client will grab it over https before first connection and when key suddenly changes.
  - deleted 1y ago
    [deleted]
  - kbolino 1y ago
    I think your proposed solution is a great idea, but we're evaluating it at the wrong layer of the software stack. The real problem is Git(Hub)'s (mis-)use of SSH, not SSH itself per se. Adding full TLS and HTTP stacks to SSH clients would be massive bloat and a security/maintenance burden that OpenSSH, PuTTY, etc. probably don't want to take on. Whereas, it would be much easier for Git to add this functionality to its client, since it already has HTTPS support. I think we could also attack this problem from the angle of phasing out git+ssh protocol (or at least greatly reducing its use) by improving unattended/headless HTTPS user authentication.