Re: NetScape's dependence upon RSA down for the count!

> 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

In article <9510010446.AA11983@dmsd.com>, jbass@dmsd.com (John L. Bass) writes:
> 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.

  This is kind of silly.  If someone can patch the binary on the fly as
you are downloading it, then all is lost, since they could just patch
it to send them copies of any information they wanted.

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

  I really don't understand what you are saying here.  Do you mean that
you could intercept a real server's certificate request, and substitute
your own private key, and then intercept the response?  This could be
easily detected by the CA and the server operator, and I think is just
a policy issue for the CA.

	--Jeff

-- 
Jeff Weinstein - Electronic Munitions Specialist
Netscape Communication Corporation
jsw@netscape.com - http://home.netscape.com/people/jsw
Any opinions expressed above are mine.