In message <Pine.BSO.4.21.0004281457540.31198-100000@dqc.org>, 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.
Steve, At 10:48 PM 04/28/2000 -0400, Steven M. Bellovin wrote:
As for the expense of ssh -- the big issue is login, when a lot of public key operations are taking place.
Yes, any computational intensive process is expensive. Yes, the price is worthwhile. - paul
Date: Fri, 28 Apr 2000 23:09:19 -0400 From: Paul Ferguson <ferguson@cisco.com> Sender: owner-nanog@merit.edu
Steve,
At 10:48 PM 04/28/2000 -0400, Steven M. Bellovin wrote:
As for the expense of ssh -- the big issue is login, when a lot of public key operations are taking place.
Yes, any computational intensive process is expensive.
Yes, the price is worthwhile.
Totally agreed. We have been pushing Cisco toward SSH for years and are very pleased that they were agreeable to looking at it before the need hit them in the faces. (I do wish they had gotten serious about it a bit sooner, though!) Other vendors are better and worse. Juniper has always had full SSH support. Of course, this is not too hard for them since they run FreeBSD on their platforms and OpenSSH is a standard part of that OS. But one of our major switch vendors (whom I'll leave unnamed at the moment, pending their response to our requests) had engineers who had no idea what SSH was. They thought it was a Unix shell, like tcsh, with enhanced security! When I told them that both Cisco and Juniper support SSH, they did become interested, but I will need to wait another few weeks to see if they are really going to do something. I'm sure some other vendors are as bad or worse. Cisco is NOT the entire network world (even if it sometimes seems like it). R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634
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.
Since we are going into a description of cryptography, we might as well bring up that since the random number generator used to generate the supposedly random RSA key pair _is_ predictable, the whole idea of perfect security is improbable at best; the exercise does make it difficult for people with only a casual interest in your operations to directly compromise them. For those who are paranoid about their serial cables traversing shared trunk space, there are inline 3DES (and other algorithm) serial line encryptors that will effectively mask your traffic if you are worried about direct (conductive) or indirect (inductive) tapping. When deciding on how much energy and effort one wants to spend on securing a network, especially if one doesn't want to actually learn the underlying technology (and who would?), it helps to identify the enemy. Is it a foreign government or just a 12 year old? If its the former, you shouldn't be in public colo space (at the very least) and if its the latter, how is he getting into the colo in the first place? Deepak Jain AiNET
Since we are going into a description of cryptography, we might as well bring up that since the random number generator used to generate the supposedly random RSA key pair _is_ predictable ... [split]
This statement is a litle too broad. I would contest that the design of, say, FreeBSD's /dev/random permits sufficient entropy collection to usefully initialise a strong hashing algorithm with a non-predictable vector.
[split] ... the whole idea of perfect security is improbable at best; the exercise does make it difficult for people with only a casual interest in your operations to directly compromise them.
This statement hits the mark, but I like to be explicit, to scare security neophytes: if you have ever crossed-over passwords, shared them between two systems, or made any kind of assumption that means the security of one password has depended on the security of another then all such linked accounts passwords are potentially compromised simultaenously. If you're paranoid enough to accept that, then : a) maybe your security could be good enough b) perhaps you should consider using SSH key agents rather than passwords. - joshua
This statement is a litle too broad. I would contest that the design of, say, FreeBSD's /dev/random permits sufficient entropy collection to usefully initialise a strong hashing algorithm with a non-predictable vector.
Okay, you know where I was going. Simple question - where are you finding entropy in a FreeBSD machine? (sufficient being a very relative term) Not intending to scare anyone. Deepak Jain AiNET
IMHO, this is a rathole. While the science behind the implementation of ecryption algorithms, in general, may be less than perfect. The engineering behind the implementation is "good enough", for various flavors of data usability persistance. Encryption only has to protect its data for that time when the release of that data may be detrimental. The absolute best encryption methods only slow down the cracker. But, that's all it has to do. At the moment, DES is crackable in about 12 hours (see: distributed.net and eff.org). Evenso, it is sufficient to protect data which only has a useful transient half-life of 3-6 hours, such as one-time pass codes. It is certainly more secure than plain-text. Sessions using passwds, that are changed weekly, or even monthly, are certainly well protected by SSH1. Likewise, most session management packets, scripts, and configuration commands, are not useful data beyond a few weeks. The Data gets stale. OTOH, CC numbers are good for years (until the expiration date) and must be better protected. But its shelf-life is still finite. ie: I don't care if anyone knows the password that I used last Monday, because I've changed it three times since then. Likewise, if someone can crack my cyper-text 200 years from now, I will most likely be beyond careing, at that time<grin>.
From: Deepak Jain [mailto:deepak@ai.net] Sent: Saturday, April 29, 2000 1:16 PM
This statement is a litle too broad. I would contest that the design of, say, FreeBSD's /dev/random permits sufficient entropy collection to usefully initialise a strong hashing algorithm with a non-predictable vector.
Okay, you know where I was going. Simple question - where are you finding entropy in a FreeBSD machine? (sufficient being a very relative term)
Not intending to scare anyone.
Deepak Jain Sent: Friday, April 28, 2000 8:49 PM
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.
Since we are going into a description of cryptography, we might as well bring up that since the random number generator used to generate the supposedly random RSA key pair _is_ predictable, the whole idea of perfect security is improbable at best; the exercise does make it difficult for people with only a casual interest in your operations to directly compromise them.
Not quite true. Sure, Netscape ran into that problem with early SSL code, in Navigator v3.0, but there are known solutions. After all, Netscape found it. Are you speaking towards a specific vulnerability in SSH, or just theory? I am not aware on such a vulnerability in SSH, or SSHD, either version 1 or 2.
For those who are paranoid about their serial cables traversing shared trunk space, there are inline 3DES (and other algorithm) serial line encryptors that will effectively mask your traffic if you are worried about direct (conductive) or indirect (inductive) tapping.
Inline encryptors are overly expensive (two per serial line). Yet, I don't see any other way to secure the console serial port, other than not using shared trunk space.
When deciding on how much energy and effort one wants to spend on securing a network, especially if one doesn't want to actually learn the underlying technology (and who would?), it helps to identify the enemy. Is it a foreign government or just a 12 year old? If its the former, you shouldn't be in public colo space (at the very least) and if its the latter, how is he getting into the colo in the first place?
I don't think that it's either extreme. The most common source of these sorts of problems are disgruntled emloyees, either yours, or one from a co-lo customer (who has access to your co-lo space). A rogue SA, or BOFH. Just using a pair of dykes, on the network fabric, is both criminal and leaves evidence of vandalism. Tapping into the co-lo providers switch system, and wreaking havoc there, takes your employers system down effectively and leaves no traces, as long as you don't care about collateral damage to the other co-lo provider customers. In fact, such a person would want as much collateral as possible, in order to mask their tracks. Yes, I agree, it helps to identify the opponent.
Not quite true. Sure, Netscape ran into that problem with early SSL code, in Navigator v3.0, but there are known solutions. After all, Netscape found it. Are you speaking towards a specific vulnerability in SSH, or just theory? I am not aware on such a vulnerability in SSH, or SSHD, either version 1 or 2.
I am not speaking of any particular vulnerability in SSH, SSHD or any specific algorithm in general. I do not want to get into a discussion of whether 3DES is safe or not, whether IDEA is safe or not etc. Everything uses a key, the strength of the data encoded by an algorithm is determined by the quality of that key. In general implementation, Diffie-Helman is used to negotiate a set of public key (RSA) style keys, which are then used to generate session keys for the underlying (somewhat faster algorithm). If the key used to generate the initial keys is predictable, everything else is too. They all operate on the concept of using an algorithm (on the host/key generating system) to create numbers of a "specific randomness." There is no element that can be used for programming in systems that is at all random, and usually just time indexed fourier algorithms. That is all. All Netscape did was add a few more variables to their "randomness" to make it less less to approximate it. Using nuclear decay plots (from a live isotope) used to be a good source for randomness too, but then they figured out how to approximate that too. This is not sci.crypt, so I suspect I am seriously off topic. There are plenty of well understood methods to prevent commercial sabotage/espionage, none of which involve cloak and dagger stuff. Implementing technology without establishing/training your human staff properly is nearly useless; if you are trying to protect against someone who knows your procedures and has the slightest bit of motivation to screw with you. Deepak Jain AiNET
I don't think so. There is even a port of ssh to the Palm Pilot. In this day and age, I think that saying that encryption is expensive is a myth. Even if it were, I think the security that it buys you is well worth it. Also, most new(er) and high end routers out there should have more than enough processing power to handle ssh, no? I know ours does. Bora "Steven M. Bellovin" wrote: <<snip>>
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.
On Fri, Apr 28, 2000 at 09:06:16PM -0700, Bora Akyol wrote:
I don't think so.
There is even a port of ssh to the Palm Pilot.
In this day and age, I think that saying that encryption is expensive is a myth.
Even if it were, I think the security that it buys you is well worth it.
Also, most new(er) and high end routers out there should have more than enough processing power to handle ssh, no? I know ours does.
But this is really a minor part of the issue, IMO. You have to SSH in from somewhere... Are your NOC machines patched and secure? Does anyone log in to these machines from home or the NANOG terminal room? Are _all_ of those machines secure, not just _your_ machine(s)? Are you positive the people watching your network when you are at home sleeping haven't done anything dumb (e.g. run an exploitable irc client) from their own machines or the "trusted" NOC machines? Are you sure your personnel don't use the same password for TACACS that they use for their favorite MUD? I suspect it is more likely that the latest cracker weenie gained access to a unix box in a key location rather than gaining some sort of physical access to sniff passwords over the line. Austin
participants (8)
-
Austin Schutz -
Bora Akyol -
Deepak Jain -
Joshua Goodall -
Kevin Oberman -
Paul Ferguson -
Roeland Meyer (E-mail) -
Steven M. Bellovin