1995-10-01 - Re: NetScape’s dependence upon RSA down for the count!

Header Data

From: jbass@dmsd.com (John L. Bass)
To: Eric Murray <ericm@lne.com>
Message Hash: 7bed974e84eb3a4a18228180c5c8a3f16a193ee6d4f9d9d59871576a1f95a58e
Message ID: <9510010446.AA11983@dmsd.com>
Reply To: N/A
UTC Datetime: 1995-10-01 04:46:56 UTC
Raw Date: Sat, 30 Sep 95 21:46:56 PDT

Raw message

From: jbass@dmsd.com (John L. Bass)
Date: Sat, 30 Sep 95 21:46:56 PDT
To: Eric Murray <ericm@lne.com>
Subject: Re: NetScape's dependence upon RSA down for the count!
Message-ID: <9510010446.AA11983@dmsd.com>
MIME-Version: 1.0
Content-Type: text/plain


> BTW your 'offer' is silly- this is not a trivial amount of work, and you
> would not deserve any credit for coming up with so ordinary an
> attack.  Write the code yourself, or pay the market rate for it.
> -- 
> Eric Murray  ericm@lne.com  ericm@motorcycle.com  http://www.lne.com/ericm

So is the Tee Shirt offer, and so is cracking the RSA public key
algorithm ... the point is that at least two teams did it.

My offer is trival in $$'s I agree, but the challenge I offer is to
focus on the weaknesses of SSL rather than it's strengths (large keys).
I suspect this is easier than most people think, so maybe I should
offer a Tee Shirt instead?

I suspect the certificates can be attacked in one of several ways.

The most likely is that the filter can use the servers certificate and fake,
forge, or simply subsititue a valid one in the filters name for the client.
This might mean that the filter has to become a trusted server as well.
I don't see any problems with the filter playing client to the server
given the SSL protocol.

Another is since the clients are often distributed
over the net, that another filter is installed recognize clients and alter
them on the fly to avoid the client/filter problem in the future.

Another tack is based on getting very close to the server (in a bridge or
router in the direct path to the server) in which the filter might acutally
be able to get the get valid certificates signed in the servers name, while
eating the real requests.

The reality is that all three parties are strangers, and I have had doubts
about the very nature of certificates & public key in this case.

John Bass
DMS Design






Thread