4 ms·

No, I'd like sites to be able to present a CA to trust rather than a static key to trust and then be able to rotate their keys without triggering identity chang

by mjg59 4y ago

No, I'd like sites to be able to present a CA to trust rather than a static key to trust and then be able to rotate their keys without triggering identity change notices.

jmclnx 4y ago
This stuff is a bit over my head. Under this scenario, if the site rotates their key, will I need to decide on my system to trust it or not ? Maybe change something on my system ? Or does the remote site use my ssh public key transparently to know it is me, and allow me in ? So I do nothing at my end ? I guess that would be OK by me. But as I noted above, I am guessing.
- _cenw 4y ago
  Your key is not involved here at all. You can also sign host keys and then trust the CA instead of the host key with TOFU, but as mentioned in the article, there's no way to do this without having the user fiddle with their SSH config and I'm unsure how good the tooling for distributing revocations is. Vault has a setup guide, along with the little dance a user would have to do: https://developer.hashicorp.com/vault/docs/secrets/ssh/signed-ssh-certificates#host-key-signing https://developer.hashicorp.com/vault/docs/secrets/ssh/signe...
- mjg59 4y ago
  Under this scenario you wouldn't need to do anything if the site rotates their key - the new key would be presented with a certificate signed with the same CA key. But no clients support doing this kind of semi-automated enrollment at the moment. You can manually add the trusted certificate to known_hosts, though.
  - jmclnx 4y ago
    Great, thanks
- unethical_ban 4y ago
  The way I understand SSH interaction, is that every single time I login to a site or server for the first time, it is like interacting with self-signed HTTPS cert. There is no PKI, no central trust that did any kind of validation that the site is who they say they are. Considering that SSH is generally used by a small number of people per server vs. a general access mechanism (for the general internet), the need for PKI hasn't seemed as pressing. But why it isn't more prominent, I don't know.
- crote 4y ago
  If I understand it correctly, there would be zero change for the user. Right now, a server has a single host key. This is generated once and will remain static for the server's entire lifetime. The client has the public part of that in their authorized_keys. When a session is created, the server uses the private part to sign some stuff, and the client validates it using the already-known public key. In other words, we have the host key K, client stores K_public in known_hosts. On session creation, server does `session_signature = K_private.sign(data)` and sends (data, session_signature) to client. Client does `K_public.validate(session_signature, data)` and continues if it all matches. This usually works just fine, but you can only have a single key for a server - which is a bit of an issue if that "server" is actually an entire cluster consisting of thousands of machines. Every singly machine needs to have a copy of the single private key. as delegating this to a secure enclave is unfeasible if you get hundreds of thousands of connections per second. Not to mention that key rotation is a bit of a nightmare. With this proposal, we add a parent key, let's call it L. L_private is stored in some kind of very secure hardware enclave. Every hour/day/whatever, the server generates a new host key K, and asks the enclave to sign the new public key. The server now has K_private, and `host_signature = L_private.sign(K_public)` as generated by the enclave. The client stores L_public in their known_hosts. On session creation, server does `session_signature = K_private.sign(data)` and sends (data, session_signature, K_public, host_signature) to the client. The client finally does `L_public.validate(host_signature, K_public) && K_public.validate(session_signature, data)`. All of this happens on the server side, and the only thing needed is a relatively minor protocol upgrade. The interesting part is that a very similar mechanism already exists for the client's key, making it way easier to manage hundreds of keys across thousands of servers without going crazy by having to update authorized_keys among the entire server fleet multiple times per week.
jacobr1 4y ago
It would be better at an intermediate cert level. Those are generally more aligned to an organization's boundaries.
- mjg59 4y ago
  The format doesn't support intermediates.
Karellen 4y ago
What about a way to sign the new key with the old key? If the host presents a new key, plus a signature from the old key which you already trusted, then your system switches to trusting the new key? I can see that there are problems in that if you don't attempt to log in between when the new key is issued and the old key expires, then you won't be able to trust the switch and will have to re-authenticate via external means. That might be a problem, but it might be easier for some groups of people to manage than figuring out a whole new CA model?
- mjg59 4y ago
  That's fine for orderly transitions, but if you're worried that your private host keys have been compromised then (a) you can't trust any new transitions and (b) if the new private keys are already on the systems then have they also been compromised?
  - tialaramex 4y ago
    However, we don't need to have the new private keys in order to tell people about the new public keys using our old private keys. If a valid emergency private key lives in the safe, realistic bad guys (who don't do black bag jobs, they just read bug lists and act quickly) can't have that key until you put it into use. So you could have a situation where say, you schedule key replacement every 12 months, you always immediately generate and announce the next key, but it lives in the safe until the rotation happens or something goes wrong and you use it immediately.
  - firstlink 4y ago
    The automatic transition would not cause additional harm in the compromise scenario and would in fact marginally help. A client which has not got an out-of-band revocation/update of the host key is subject to complete mitm'ing and impersonation either way: tricking it into accepting a new fraudulent host key doesn't actually make this scenario worse, it only means the first attacker locks out his competition :). (An out-of-band key update still fixes the client.) OTOH, if the client happens to connect to the authentic host first, then it is saved. So, no net harm, marginal net benefit.
soulofmischief 4y ago
SSH certificates already enable this. I use them in prod.

by mjg59 4y ago

No, I'd like sites to be able to present a CA to trust rather than a static key to trust and then be able to rotate their keys without triggering identity change notices.

jmclnx 4y ago

This stuff is a bit over my head. Under this scenario, if the site rotates their key, will I need to decide on my system to trust it or not ? Maybe change something on my system ? Or does the remote site use my ssh public key transparently to know it is me, and allow me in ? So I do nothing at my end ? I guess that would be OK by me. But as I noted above, I am guessing.

_cenw 4y ago
Your key is not involved here at all. You can also sign host keys and then trust the CA instead of the host key with TOFU, but as mentioned in the article, there's no way to do this without having the user fiddle with their SSH config and I'm unsure how good the tooling for distributing revocations is. Vault has a setup guide, along with the little dance a user would have to do: https://developer.hashicorp.com/vault/docs/secrets/ssh/signed-ssh-certificates#host-key-signing https://developer.hashicorp.com/vault/docs/secrets/ssh/signe...
mjg59 4y ago
Under this scenario you wouldn't need to do anything if the site rotates their key - the new key would be presented with a certificate signed with the same CA key. But no clients support doing this kind of semi-automated enrollment at the moment. You can manually add the trusted certificate to known_hosts, though.
- jmclnx 4y ago
  Great, thanks
unethical_ban 4y ago
The way I understand SSH interaction, is that every single time I login to a site or server for the first time, it is like interacting with self-signed HTTPS cert. There is no PKI, no central trust that did any kind of validation that the site is who they say they are. Considering that SSH is generally used by a small number of people per server vs. a general access mechanism (for the general internet), the need for PKI hasn't seemed as pressing. But why it isn't more prominent, I don't know.
crote 4y ago
If I understand it correctly, there would be zero change for the user. Right now, a server has a single host key. This is generated once and will remain static for the server's entire lifetime. The client has the public part of that in their authorized_keys. When a session is created, the server uses the private part to sign some stuff, and the client validates it using the already-known public key. In other words, we have the host key K, client stores K_public in known_hosts. On session creation, server does `session_signature = K_private.sign(data)` and sends (data, session_signature) to client. Client does `K_public.validate(session_signature, data)` and continues if it all matches. This usually works just fine, but you can only have a single key for a server - which is a bit of an issue if that "server" is actually an entire cluster consisting of thousands of machines. Every singly machine needs to have a copy of the single private key. as delegating this to a secure enclave is unfeasible if you get hundreds of thousands of connections per second. Not to mention that key rotation is a bit of a nightmare. With this proposal, we add a parent key, let's call it L. L_private is stored in some kind of very secure hardware enclave. Every hour/day/whatever, the server generates a new host key K, and asks the enclave to sign the new public key. The server now has K_private, and `host_signature = L_private.sign(K_public)` as generated by the enclave. The client stores L_public in their known_hosts. On session creation, server does `session_signature = K_private.sign(data)` and sends (data, session_signature, K_public, host_signature) to the client. The client finally does `L_public.validate(host_signature, K_public) && K_public.validate(session_signature, data)`. All of this happens on the server side, and the only thing needed is a relatively minor protocol upgrade. The interesting part is that a very similar mechanism already exists for the client's key, making it way easier to manage hundreds of keys across thousands of servers without going crazy by having to update authorized_keys among the entire server fleet multiple times per week.

jacobr1 4y ago

It would be better at an intermediate cert level. Those are generally more aligned to an organization's boundaries.

mjg59 4y ago
The format doesn't support intermediates.

Karellen 4y ago

What about a way to sign the new key with the old key? If the host presents a new key, plus a signature from the old key which you already trusted, then your system switches to trusting the new key? I can see that there are problems in that if you don't attempt to log in between when the new key is issued and the old key expires, then you won't be able to trust the switch and will have to re-authenticate via external means. That might be a problem, but it might be easier for some groups of people to manage than figuring out a whole new CA model?

mjg59 4y ago
That's fine for orderly transitions, but if you're worried that your private host keys have been compromised then (a) you can't trust any new transitions and (b) if the new private keys are already on the systems then have they also been compromised?
- tialaramex 4y ago
  However, we don't need to have the new private keys in order to tell people about the new public keys using our old private keys. If a valid emergency private key lives in the safe, realistic bad guys (who don't do black bag jobs, they just read bug lists and act quickly) can't have that key until you put it into use. So you could have a situation where say, you schedule key replacement every 12 months, you always immediately generate and announce the next key, but it lives in the safe until the rotation happens or something goes wrong and you use it immediately.
- firstlink 4y ago
  The automatic transition would not cause additional harm in the compromise scenario and would in fact marginally help. A client which has not got an out-of-band revocation/update of the host key is subject to complete mitm'ing and impersonation either way: tricking it into accepting a new fraudulent host key doesn't actually make this scenario worse, it only means the first attacker locks out his competition :). (An out-of-band key update still fixes the client.) OTOH, if the client happens to connect to the authentic host first, then it is saved. So, no net harm, marginal net benefit.

soulofmischief 4y ago

SSH certificates already enable this. I use them in prod.