Slashdot Mirror
OpenSSH Will Feature Key Discovery and Rotation For Easier Switching To Ed25519
ConstantineM writes: OpenSSH developer Damien Miller has posted about a new feature he implemented and committed for the next upcoming 6.8 release of OpenSSH — hostkeys@openssh.com — an OpenSSH extension to the SSH protocol for sshd to automatically send all of its public keys to the client, and for the client to automatically replace all keys of such server within ~/.ssh/known_hosts with the fresh copies as supplied (provided the server is trusted in the first place, of course). The protocol extension is simple enough, and is aimed to make it easier to switch over from DSA to the OpenSSL-free Ed25519 public keys. It is also designed in such a way as to support the concept of spare host keys being stored offline, which could then seamlessly replace main active keys should they ever become compromised.
Agreed - this makes sense if you want to display a message to the user: "The server is advertising updated host keys via the trusted channel. Do you want to add them to your local host key list?"; but automatically replacing them without prompting seems overeager...
"Go to CNN [for a] spell-checked, fact-checked summary" -- CmdrTaco
Yeah, but it's also easier to compromise a host, send out fake server keys, and then patch things up so the server looks fine again but intercept targeted clients. ...
I didn't RTFA, but based on the summary it seems like this is unlikely.
If you can compromise a host to the point that you have read access to the private host key, then your MITM can simply use that private key. No need to change to a new key to exploit that. AFAICT, you would need access to the existing host key pair in order to sign the new keys. If this was done right, then it seems like this would be adding very little (if any) additional risk.
That said, I'd want to have the option of being prompted. I could set that for all my interactive shells (or it could be the default), and I could set my automated jobs to auto-sync the new keys.
Correct me if I'm wrong but this can only take place after a fully authenticated session.
If the NSA is in a position to MITM this connection then they are likely already in the possession of all necessary keys at either end and gain nothing by being able to send the client and server new keys.
How can NSA not loving this feature?
I mean, the two way encrypted channels between userA and serverA, if NSA would like to crack it, they would need to invest some crunch time just to take a peek
With this new protocol all NSA needs to do is to perform a MITM act ... get the info needed and then tell the user (and the server) to update keys and such
Mission accomplished !
Let's not go over the top with this. When you say "all NSA needs to do is to perform a MITM act" you are forgetting that the default for SSH is to abort during a MITM. That means they are back at needing "to invest some crunch time just to take a peek". The only loss is that, if they did compromise a server or manage to get into the encrypted channel they could potentially leverage that for a silent compromise of the client side key without thaat being visible on the host. It's still a pretty high risk attack for pretty low gain compared to what they have to already have (the ability to compromise some SSH connections).
Firstly, let's not just talk about the NSA. There are plenty of other bad actors and don't forget the Chinese and Russians also have pretty hot capabilities. Weakening crypto helps the enemy of all kinds. People who suggest reducing encryption knowing that, and I think most of them do, are traitors.
There should be a warning on key replacement or, better, a warning when the new key is taken into use. This would be important in the case where the enemy could compromise some connections but not others and then use key replacement to escalate that to all connections.
So, I have to trust a server to automatically replace a trusted key with a new trusted key.
Yeah, this is the type of thing I'll try when it's been in the code for five, ten years.
I'm perfectly sure, as a mathematician, that you can use some kind of secure exchange to make this work but - fuck - I won't be trusting implementations of it for a while.
Isn't this exactly the sort of thing that, half-assed, will generate security problems for years to come and yet still seems to be outside the SSH protocol and has to be a custom extension? Is there an RFC for this?
Sorry but as far as I'm concerned key management shouldn't be a part of the process that's handling connection authentications, etc. Why can't this be an outside protocol entirely? For decades, we've been waiting for some kind of automated decentralised, anonymised key-store and surely the effort going into securing this very dangerous piece of code would have been better put into moving the problem away from SSH and allowing multi-protocol use of such things.