Catch up on stories from the past week (and beyond) at the Slashdot story archive

 



Forgot your password?
typodupeerror
Check out the new SourceForge HTML5 internet speed test! No Flash necessary and runs on all devices. ×
Security Software

OpenSSH Will Feature Key Discovery and Rotation For Easier Switching To Ed25519 88

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.
This discussion has been archived. No new comments can be posted.

OpenSSH Will Feature Key Discovery and Rotation For Easier Switching To Ed25519

Comments Filter:
  • by Anonymous Coward
    How about 'no'.
    • by stoborrobots ( 577882 ) on Sunday February 01, 2015 @03:24AM (#48950391)

      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...

      • Although, in hindsight - you've already authenticated the server, so you are going to treat it as a trusted party anyway...

        • by Anonymous Coward

          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. Even if the server would push out only its current whitelisted keys and they completely replaced known_hosts, users who are already MitM'd wouldn't see that until they can establish a connection to the real server, which they might not even trust anymore due to known_hosts being changed by the MitM. In short, it sounds dangerous. By all means

          • Re: (Score:3, Insightful)

            by unrtst ( 777550 )

            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

        • Re: (Score:2, Interesting)

          by Anonymous Coward

          Although, in hindsight - you've already authenticated the server, so you are going to treat it as a trusted party anyway...

          Agreed, but *I* would still like to be prompted anyways. The same way when it comes to things like windows or app "automatic updates" I always pick the "notify me, but don't download/update without asking" option. I like to *know* what's happening to my systems, and have the option to say NO, even if it's probably unlikely.

        • Although, in hindsight - you've already authenticated the server, so you are going to treat it as a trusted party anyway...

          There's trust, and then there's TRUST. Doing something like this automatically is like doing automatic updates ... not a good idea.

    • 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 !

      • by thegarbz ( 1787294 ) on Sunday February 01, 2015 @05:04AM (#48950591)

        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.

      • by Anonymous Coward on Sunday February 01, 2015 @05:26AM (#48950633)

        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.

        • by DarkOx ( 621550 )

          Right, I don't see much risk here, and probably loads of to gain in terms of replacing old DSA keys. The only place where I see something like this complicating things in terms of security is now the key store might be changing without user awareness so if you are doing something like having the key store monitored with tripwire or the like you might have an issue.

          I suspect people who are going to those kind of lengths probably parse the change logs to security central items like openssh pretty carefully b

        • > ou are forgetting that the default for SSH is to abort during a MITM

          With stolen hostkeys on the same IP address? Or by presenting a new host IP in DNS with their own MITM keys, connecting to an unencrypted login transaction logger, and recording the user login attempt and passwords, then using them next time to connect to forward the connection to the relevant upstream host? Or any of a dozen other MITM approaches?

          I've been through just such an attack. Fortunately, the person doing the attack gave the

    • Agreed. I want to know if my servers' keys have changed unexpectedly. You can set UpdateHostkeys No to turn this off; I'd like the option of UpdateHostkeys Prompt.

      I do understand that having Prompt as the default would undermine the intended use case somewhat, but I think it would be good to have the option.

    • How about 'no'.

      Agreed.

      Consider the situation where an attacker has actually compromised a server key - either it was leaked, brute forces, a vulnerability exploited. It happens and big parts of the certificate system such as revocation lists, OCSP, validity periods etc are concerned with this. Or consider the situation where a vulnerability allows the attacker to *fake* the fact that he has the private key.

      Many systems are set up to warn or outright block if they are not able to check revocation for a certain time period.

      • logic fails you. we're talking about public keys; after logging into a server via ssh you can already replace or change lines in .known_hosts anyway.

    • How about 'no'.

      If you didn't trust your connection to the server in the first place, then what was the point of using SSH?

  • Maybe it's off-topic, but is it just me who see potentially big problems with ed25519.c? e.g. http://bxr.su/OpenBSD/usr.bin/ssh/ed25519.c#25 [bxr.su]

    Hint: no input validation, hard-coded array offsets with no clue about their expected size, etc...

    I know, it's open-source (I should contribute, blablabla) but I see this kind of problems all over that code base.

    • It is an internal function so the input validation should have already happened.
      The hard coded offsets look like they are part of how the crypto works.

      • It is an internal function so the input validation should have already happened.

        That's adorable.

    • by Anonymous Coward
      The OpenBSD/OpenSSH team is regarded as being considered paranoid to paranoid people. They have a long track record of great decisions, excellent design, and excellent code quality. They are known to error on the side of caution and are the standard for security.
    • by gurnec ( 1011007 )

      Keep in mind that this is crypto code, which often has different properties and requirements than other types of code.

      For example, the count of bytes to store a private key, or a finite field element, or a hash output, etc. is hard coded and never changes. It would be akin to asserting that the sizeof a uint32_t is 4 somewhere in your code.... not very useful. Perhaps some defines would be nice from a documentation point of view, but that's more a style choice.

      Input validation must be handled very carefully

      • Thank you, I think you're right.
        My comments above were probably due mainly to ignorance.
        After all I've never bothered looking at that code before and should have studied the whole thing before judging... well... the whole thing.

    • It's a signature algorithm. It should take any input and sign it.

  • We need keys and host passwords checked as authentication types without having to revert to PAM hackery. Just how many systems have been exploited because some root process found a way to read some .ssh/keys and then hopped to other systems with no human intervention.

  • by heikkile ( 111814 ) on Sunday February 01, 2015 @08:03AM (#48950899) Homepage

    If I read the article (or even the summary) correctly, this is about updating the known_hosts file, not authorized_keys. So, even with this enabled, this only affects the "The hostkey has changed" warning message, not who can log in with which keys. Although I am a tad uneasy about automatic key updates, this seems to be fairly safe, and it makes it so much easier to change a hostkey, without bothering all the users of a system.

  • Dangerous because automatic key updates should require a great deal of verification of the new keys. I could imagine some scenarios (e.g. cloned virtual machines), which lead to the authenticated key being correctly updated (e.g old instructions/documentation) by the admin, but the EC key not overwritten (since it's not in the standard procedure). If this EC key then is copied automatically to the client, any of the cloned machines would accepted as a verified server after the login.

    Overkill because exposin

  • No thanks, I'll pass on this feature.
  • SSH (Score:4, Insightful)

    by ledow ( 319597 ) on Sunday February 01, 2015 @10:02AM (#48951161) Homepage

    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.

    • So, I have to trust a server to automatically replace a trusted key with a new trusted key....

      You don't have to do anything. You can use this feature if it is suitable for your needs and security requirements. If it is not, then no one is forcing you to use it, so don't.

    • by Anonymous Coward

      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.

      If only SSH had some sort of way of, say, encrypting the channel over which you communicate. And if only there were some way to know that you previously acknowledged that you trusted the server.

      Maybe that would help?

    • 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.

      If you trust a server by accepting its public key, it is by definition, trusted, for as long as its private key is secure.
      Only the initial trust needs to be verified by humans, and with a chain of trust, even that can be nearly automated by adding your organization's CA key when systems are deployed (I'm in an imaginary world where SSH key management has caught up with the rest of the world).
      The older a private key gets, the more likely it has been compromised, maybe by VM cloning, backup media leaking, etc

    • So, I have to trust a server to automatically replace a trusted key with a new trusted key.

      You have already trusted a server, and connected to it in a secure fashion, and authenticated. At that point why would you not trust it to replace the key?

  • by Anonymous Coward

    This is so typical of the current OpenSSH maintainers, it actually hurts to watch.

    The actual problem is that there's no client tool for clearing replaced keys. You hve to open up your "authorized_keys" file with a text editor or the client keeps moaning "oh, no, the key doesn't match, boo-hoo-boo-hoo!!" even when you know damn well you rebuilt the host and it has new keys, or a dozen similar situations. If the software is smart enough to read and detect old and not matched recorded host keys, it should be i

    • by gweihir ( 88907 )

      Might be a canary, i.e. a test of how much stupidity and potentially insecure automation OpenSSH users are willing to accept. In that case the OpenSSH maintainers team is not stupid, but has been compromised. Would make sense...

If a 6600 used paper tape instead of core memory, it would use up tape at about 30 miles/second. -- Grishman, Assembly Language Programming

Working...