[956] in WWW Security List Archive
Re: NetScape's dependence upon RSA down for the count!
daemon@ATHENA.MIT.EDU (Don Stephenson)
Sat Sep 30 23:23:49 1995
Date: Sat, 30 Sep 1995 17:03:48 -0700
From: Don.Stephenson@eng.sun.com (Don Stephenson)
To: www-security@ns2.rutgers.edu, cypherpunks@toad.com, jbass@dmsd.com
Errors-To: owner-www-security@ns2.rutgers.edu
I haven't read the SSL spec for a while but my understanding was that
the server passed it's public key to the client via a certificate
signed by a mutually trusted certificate authority (i.e., Verisign).
How would the filter be able to forge such a certificate ?
- Don
> From jbass@dmsd.com Sat Sep 30 16:47:11 1995
> Date: Sat, 30 Sep 95 16:39:57 -0600
> From: jbass@dmsd.com (John L. Bass)
> To: www-security@ns2.rutgers.edu, cypherpunks@toad.com
> Subject: Re: NetScape's dependence upon RSA down for the count!
>
> > jbass@dmsd.com writes:
> > > client -> filter Client sends packet with K(c)
> > filter -> Server filter forwards packet with K(f) filter <- Server Server sends encrypts with K(f)
> > > client <- filter filter re-encrypts with K(c)
> > >
> > > As the protocol progresses the filter also uses the master key,
> > > and follows the renegotiation as the master key expires.
> >
> > Yeah, but in order for this to work, the fake server needs to know
> > netscape.com's private (secret) key, no?
> >
> > -jon
>
> No ... the public part of any server private key is held by the filter
> and not returned to the client. The client only encrypts with public
> keys provided by the filter. The Server only encrypts with public keys
> provided by the filter. The filter has cleartext of the entire session.
>
> John
>
>
