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

Header Data

From: jsw@neon.netscape.com (Jeff Weinstein)
To: cypherpunks@toad.com
Message Hash: c11a2a8d094f4a50fdedd07808b31c077ad19eb4b4d81de3664e4d7d6dc5836d
Message ID: <44mtu4$59h@tera.mcom.com>
Reply To: <9510010446.AA11983@dmsd.com>
UTC Datetime: 1995-10-01 20:33:37 UTC
Raw Date: Sun, 1 Oct 95 13:33:37 PDT

Raw message

From: jsw@neon.netscape.com (Jeff Weinstein)
Date: Sun, 1 Oct 95 13:33:37 PDT
To: cypherpunks@toad.com
Subject: Re: NetScape's dependence upon RSA down for the count!
In-Reply-To: <9510010446.AA11983@dmsd.com>
Message-ID: <44mtu4$59h@tera.mcom.com>
MIME-Version: 1.0
Content-Type: text/plain


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.





Thread