RE: ABOVE.NET SECURITY TRUTHS?

["Roeland Meyer (E-mail)" <rmeyer () mhsc com>]

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