// COMPLETE THREAD

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

3 expanded posts ยท every known parent and child

NODE f86cf190Re: 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
NODE 42ec5c54Re: 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.

What you have described is the classic 'man in the middle' attack.
Netscape claims that SSL V.3 is immune to the MITM attack in
appendix D.4 of the SSL V.3 spec. 

You will need to get the 'filter' (MITM) key signed by Verisign.
Or hack Verisign's server-key-signing key.


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
PGP keyid:E03F65E5 fingerprint:50 B0 A2 4C 7D 86 FC 03  92 E8 AC E6 7E 27 29 AF
NODE 342e6079Re: NetScape's dependence upon RSA down for the count!
On Sat, 30 Sep 1995, Eric Murray wrote:

> What you have described is the classic 'man in the middle' attack.
> Netscape claims that SSL V.3 is immune to the MITM attack in
> appendix D.4 of the SSL V.3 spec. 

I think you're misunderstanding the claim somewhat - what D.4 does is warn 
implementors that they should perform  some means of associating 
hostnames and certificates. You can't just use SSL out of the box without 
doing anything in the application to check. 

My currently recommended approach is to enforce the verisign requirement 
that all valid hostnames for the server be included in the certificate as 
CN values. This allows the check to be made below the application layer. 
Unfortunately a lot of currently issued certificates are non-compliant 
(even Verisign and netscape :-); any fully automated implementation needs 
a static table of hostnames aliases- interactive applications can 
display certificates for manual review.

> 
> You will need to get the 'filter' (MITM) key signed by Verisign.
> Or hack Verisign's server-key-signing key.

This is not really much protection. Getting hold of any key is much 
easier than getting a specific key, and don't forget there are a number 
of vulnerable keys floating around until their expiration dates pass. 

This attack has been known about for a long time, and is too obvious to 
be really interesting; I implemented a demonstration of the attack as 
part of developing a protection. If anybody is interested I can mail them my
report. 

The variant of the attack I implemented is useless for anything but 
demonstration purposes, or I'd ask sameer for a T-shirt. The external fix 
is a bit more useful, but there doesn't seem to be a patchnetscape alias :-)

Simon