From: ichudov@algebra.com (Igor Chudov @ home)
Date: Fri, 9 Aug 1996 10:19:43 +0800
To: pgut001@cs.auckland.ac.nz
Subject: Re: An SSL implementation weakness?
In-Reply-To: <83952437618205@cs26.cs.auckland.ac.nz>
Message-ID: <199608082324.SAA05497@manifold.algebra.com>
MIME-Version: 1.0
Content-Type: text


pgut001@cs.auckland.ac.nz wrote:
>  
> Lets say you steal www.megafoobarcorp.com.  People connect to this site (which 
> is actually your bogus site), Netscape (for example) displays the blue line 
> and non-broken key (which is actually for your J.Random certificate rather 
> than the real megafoobarcorp one) to show the connection is secure, and you've 
> just subverted their site.  
>  
> The problem is that unless the user on the client side checks their 
> certificates (which noone does), all they're told is "A secure link is 
> established", not who the secure link is established to.  Even if browsers did 
> pop up a dialog to tell them who the secured connection was to, after about 
> the third time people would click on the "Never show this incredibly annoying 
> dialog again" option and never look at it again.     
>  
> This effectively reduces an attack on an SSL-enabled server to an attack on 
> the DNS.  Is this as simple as it seems, and is it worth doing a writeup on?

I do not know much about how SSL works, but SSH (Secure Shell) has
a nice safety built in. It creates  a database of known hosts and
for each connection it matches the current host certificate (public
key) with the old public key from the ssh's database of known
hosts. If the keys mismatch, a warning is issued.

It actually works. Maybe the same logic should be used in SSL?

	- Igor.