[28434] in North American Network Operators' Group
RE: ABOVE.NET SECURITY TRUTHS?
daemon@ATHENA.MIT.EDU (Roeland Meyer (E-mail))
Sat Apr 29 13:03:36 2000
Reply-To: <rmeyer@mhsc.com>
From: "Roeland Meyer (E-mail)" <rmeyer@mhsc.com>
To: "'Deepak Jain'" <deepak@ai.net>,
"'Steven M. Bellovin'" <smb@research.att.com>
Cc: "'Chris Cappuccio'" <chris@dqc.org>,
"'Mr. James W. Laferriere'" <babydr@baby-dragons.com>,
"'Greene, Dylan'" <DGreene@navisite.com>,
"'Paul Froutan'" <pfroutan@rackspace.com>, <nanog@merit.edu>
Date: Sat, 29 Apr 2000 09:59:53 -0700
Message-ID: <006301bfb1fc$575e0e40$eaaf6cc7@PEREGRIN>
MIME-Version: 1.0
Content-Type: text/plain;
charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
In-Reply-To: <Pine.BSF.4.21.0004282344340.25013-100000@aries.ai.net>
Errors-To: owner-nanog-outgoing@merit.edu
> Deepak Jain
> Sent: Friday, April 28, 2000 8:49 PM
>=20
> > 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.
>=20
> Since we are going into a description of cryptography, we=20
> might as well
> bring up that since the random number generator used to generate the
> supposedly random RSA key pair _is_ predictable, the whole=20
> idea of perfect
> security is improbable at best; the exercise does make it=20
> 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=20
> spend on securing
> a network, especially if one doesn't want to actually learn=20
> 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,=20
> you shouldn't
> be in public colo space (at the very least) and if its the=20
> 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.
