|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: ABOVE.NET SECURITY TRUTHS?
In message <[email protected]>, Chris Cappuccio writes: > >On Fri, 28 Apr 2000, Mr. James W. Laferriere wrote: > > | > | > | Hello Dylan, Knew this was coming . But I'd hoped that > | the supported platforms would have been a little larger . > | Just the 7200 & UP . Seems cisco thinks ssh puts a bit > | of load on a cpu ? I can't see that for just a terminal > | session though . Twyl, JimL > | > >The ssh server should optimally generate new keys every so often (every few >hours?) Disable that feature; you probably don't need it in this situation. Here's what's going on. Stock sshd generates a new, relatively short, RSA key pair once an hour. This key is used to exchange the session key that actually protects the data. Your normal public/private key pair (the stuff that's in your identity and identity.pub files) is used to authenticate the exchange, rather than to transmit the session key. Why that whole song and dance? The idea is to approximate a cryptographic property known as "perfect forward secrecy". Perfect forward secrecy says that if, some time in the future, your machine is compromised, the enemy can't read past traffic. In this case, since that RSA key pair is discard hourly, and that is the only key that can decrypt the session key, our old traffic is protected. It's only readable if the machine is penetrated while that key is live. Now -- in this case, the generator of that key is the router itself. If the bad guys have enough control of the router to pry out a private RSA key -- a key for which there is no conceivable need for any API or CLI way to read -- those same bad guys can pry anything else they want out of the router, including its enable password. They can also change the configuration to make it possible to log back in without going through complicated shenanigans. The real purpose of that feature of sshd is to protect access to a multiuser system, where there's much more risk of compromise, and where more general secrets might be protected by the connection. As for the expense of ssh -- the big issue is login, when a lot of public key operations are taking place. But even output is rather expensive, since it's doing a 3DES operation for each eight output bytes. Worse yet, if the output is passed to the sshd piece a byte at a time, it will do a 3DES operation for each byte. That almost certainly happens for each keystroke, but most people don't type enough or fast enough for that to be an issue.
|