Post Acyww2pMAUsNm9LUWW by mjg59@nondeterministic.computer
(DIR) More posts by mjg59@nondeterministic.computer
(DIR) Post #AcyhduMRPPK2zbiMBk by mjg59@nondeterministic.computer
2023-12-19T20:12:11Z
0 likes, 0 repeats
Here's a blog post about trying to make SSH host certificates more usable without compromising on security: https://mjg59.dreamwidth.org/68721.html
(DIR) Post #AcyuABiBdL7tWP2oYy by beasts@social.mythic-beasts.com
2023-12-19T22:32:54Z
0 likes, 0 repeats
@mjg59 haven't thought it through, but doesn't DNSSEC + SSHFP already solve this - update key and sshfp records and away you go?
(DIR) Post #Acywlg4LvZoQISPt7w by kasperd@westergaard.social
2023-12-19T22:47:35.647136Z
0 likes, 0 repeats
I think a better approach when rotating a host or user key would be to generate a certificate which contains the new public key signed using the old private key.When presented with such a certificate the known_hosts or authorized_keys file could be automatically updated. By replacing the old public key with the new public key in all places where it is found.
(DIR) Post #AcywlgwwebTt1lxUDg by mjg59@nondeterministic.computer
2023-12-19T23:01:44Z
0 likes, 0 repeats
@kasperd There's actually already a protocol for doing that! http://blog.djm.net.au/2015/02/key-rotation-in-openssh-68.html has some details. But the problem is that it requires the server to possess the new private key as well as the old one, which means you're still at risk of disclosing both.The additional risk of rooting it in possession of the old private key is that, well, the point is you just disclosed the old private key! An attacker is equally capable of using it to rotate to a new private key under their control.
(DIR) Post #Acyww2pMAUsNm9LUWW by mjg59@nondeterministic.computer
2023-12-19T23:03:17Z
0 likes, 0 repeats
@beasts Yes, although you're then relying on all your clients having DNSSEC support and now you arguably have two problems
(DIR) Post #Acz5ZzakPuHSxP4Wau by kasperd@westergaard.social
2023-12-20T00:30:25.754219Z
0 likes, 0 repeats
I didn't know about that feature. It's not exactly the way I would have done it. It sounds like it's better than nothing, but I see a drawback in the way it's done.If you generate a new key because of a compromise you want to minimize the duration for which clients will keep accepting the old key.With my approach a client would only accept the old key next time they connect and never again after that. That means there is not really any drawback of still having the old key on the server. Having the old private key doesn't increase the risk of a leak if it was leaked already.With the actual approach clients would first have to connect once after the leak to acquire the new key and once all (or sufficiently many) clients have connected the old key can be removed. And then the clients have to connect again in order to remove the old key. So no sooner than the third connection would any client be able to reject the old key. And since clients connect at different intervals it would actually be much worse than that.What their approach is really missing is for the server to prove that it holds the old key but simultaneously tell the client that it is not to be trusted anymore.
(DIR) Post #Acz5a0O1ShhDQE7sOm by mjg59@nondeterministic.computer
2023-12-20T00:37:38Z
0 likes, 0 repeats
@kasperd As described in the blog post, you can't just hand over a new key without some evidence regarding the ownership of the private key. Using certs solves that, and it seems easier to piggy back off the existing cert infrastructure rather than introducing a new type?
(DIR) Post #Acz82Fr7jySlPrKtii by kasperd@westergaard.social
2023-12-20T01:04:09.738030Z
0 likes, 0 repeats
But certificates introduces a different private key. What are you going to do if that one was leaked?Sure when the client switches from old to new key the server needs to prove that it holds both keys. I never challenged that conclusion.What I am saying is a problem is that the server was presenting both keys as interchangeable without any indication that one is deprecated and should be removed from known_hosts immediately.
(DIR) Post #Acz82GmCJm7IGs2TgG by mjg59@nondeterministic.computer
2023-12-20T01:08:43Z
0 likes, 0 repeats
@kasperd There's no need for the CA key to be on any servers, so the associated risk should be much smaller.
(DIR) Post #AczeFREDxwaaz9THRg by beasts@social.mythic-beasts.com
2023-12-20T07:09:12Z
0 likes, 0 repeats
@mjg59 a sample size of one website suggests DNSSEC has passed the Bon Jovi threshold (woah oh, we’re halfway there) because you lose half your traffic if your signature is invalid.