3 ms·

That doesn't make any sense. Say the server is using key A, but you want to plan for the future, so you have it also offer keys B and C. But it's still using A

That doesn't make any sense. Say the server is using key A, but you want to plan for the future, so you have it also offer keys B and C. But it's still using A. So clients connect, in addition to having A, they get B and C. Great, future-proofed. Now A gets compromised. Or A is using a crappy algorithm that is easily broken. Mr. SysAdmin is happy since he's planned for this eventuality. Stop using key A, use B instead. Clients have no issues wondering if they should trust the new key (B) since they already have it in their known_hosts. Attacker comes along. Somehow A is compromised (either that's why the admin moved to B, or the crappy algo made it easy for the attacker to get the key). Attacker uses key A. Clients already trust A. Connection compromised. What I'm saying is that in this situation it would have been good if, when the server started using key B, it also had some way to send messages to client connections saying "delete A from your known_hosts" that way if someone does start using A again, it's flagged. Yes, it's still a race condition. But much better than the alternative.

cnst 12y ago
Well, I didn't look through every line of the patch, but my understanding is that once the server stops using key A, it'll automatically be revoked / deleted from the client. Why else would http://bxr.su/o/usr.bin/ssh/hostfile.c#hostfile_replace_entries http://bxr.su/o/usr.bin/ssh/hostfile.c#hostfile_replace_entr... be calling hostkeys_foreach() function with the pointer to host_delete() as the parameter? E.g. revoking the key is as easy for the server as simply no longer using it. Which is why I'm saying it's a race condition -- if the attacker comes first, it would appear that they're free to revoke every single valid key for the server, replacing all such keys with whatever keys they wish.
n_to_the_flower 12y ago
Unused private key material shouldn't just by lying around. It's better to generate it just in time, when migrating key material is needed, and use an authoritative method to distribute known hosts (Krb5, cfg mgmt). OpenSSH supports sahfp DNS records (RFC4255), but DNS often lacks end-to-end integrity. So that leaves cfg mgmt and directories like LDAP & Krb5. (PS: if a box is compromised, don't just change host keys, rebuild it (patched) on a private network... It's too expensive and nearly impossible to prove a compromised box isn't still rooted, undoing bandaids and creating more work. (Find out cause if possible and rachet up defenses too.) The avg rootkits these days are crazy modular and far more devious than even 5 years ago.) If this adds an ability to add N keys, this could be useful for core boxes that you don't want to introduce cyclic dependencies upon other infrastructure (the cycles aren't always obvious). Be aware that some boxes and services shouldn't depend on "ubiquitous" services like DHCP or DNS being alive, if you want your on-prem / datacenter network gear, BGP, security system, etc. to survive interruptions.

cnst 12y ago

Well, I didn't look through every line of the patch, but my understanding is that once the server stops using key A, it'll automatically be revoked / deleted from the client. Why else would http://bxr.su/o/usr.bin/ssh/hostfile.c#hostfile_replace_entries http://bxr.su/o/usr.bin/ssh/hostfile.c#hostfile_replace_entr... be calling hostkeys_foreach() function with the pointer to host_delete() as the parameter? E.g. revoking the key is as easy for the server as simply no longer using it. Which is why I'm saying it's a race condition -- if the attacker comes first, it would appear that they're free to revoke every single valid key for the server, replacing all such keys with whatever keys they wish.

n_to_the_flower 12y ago

Unused private key material shouldn't just by lying around. It's better to generate it just in time, when migrating key material is needed, and use an authoritative method to distribute known hosts (Krb5, cfg mgmt). OpenSSH supports sahfp DNS records (RFC4255), but DNS often lacks end-to-end integrity. So that leaves cfg mgmt and directories like LDAP & Krb5. (PS: if a box is compromised, don't just change host keys, rebuild it (patched) on a private network... It's too expensive and nearly impossible to prove a compromised box isn't still rooted, undoing bandaids and creating more work. (Find out cause if possible and rachet up defenses too.) The avg rootkits these days are crazy modular and far more devious than even 5 years ago.) If this adds an ability to add N keys, this could be useful for core boxes that you don't want to introduce cyclic dependencies upon other infrastructure (the cycles aren't always obvious). Be aware that some boxes and services shouldn't depend on "ubiquitous" services like DHCP or DNS being alive, if you want your on-prem / datacenter network gear, BGP, security system, etc. to survive interruptions.