An SSL implementation weakness?

The following weakness seems very obvious, I've got a partial writeup of this 
but before I turn it into a paper or something and arrange a demonstration of 
how it would work I thought I'd check to make sure (a) someone else hasn't 
mentioned it before, and (b) it is actually possible (it seems too simple to 
be true):
 
1. Using DNS spoofing, stage a hostile takeover of an address (for example 
   using bogus referrals set yourself up as the delegated server for a DNS 
   subtree).
2. Get a Verisign certificate for an arbitrary company and set up a bogus site 
   at the stolen address.
 
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?
 
Peter.

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.

-----BEGIN PGP SIGNED MESSAGE-----

On Fri, 9 Aug 1996 pgut001@cs.auckland.ac.nz wrote:

> The following weakness seems very obvious, I've got a partial writeup of this 
> but before I turn it into a paper or something and arrange a demonstration of 
> how it would work I thought I'd check to make sure (a) someone else hasn't 
> mentioned it before, and (b) it is actually possible (it seems too simple to 
> be true):
>  
> 1. Using DNS spoofing, stage a hostile takeover of an address (for example 
>    using bogus referrals set yourself up as the delegated server for a DNS 
>    subtree).
> 2. Get a Verisign certificate for an arbitrary company and set up a bogus site 
>    at the stolen address.
>  
> 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 domain in the server's certificate will not match the domain on the url,
i.e. the certificate will say www.eve.com and the url will be
www.megafoobarcorp.com.  Netscape does and should complain about this,
and that particular warning cannot be turned off.  Now it is quite possible
that the user will ignore the warning or not fully understand it, and 
proceed, but if the user pays attention to those sort of warnings, the
switch will be detected.

Now maybe if you got a certificate for a very similar domain name, the user
might be more likely to ignore the warning.


- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Jeremey Barrett
Senior Software Engineer			jeremey@forequest.com 
The ForeQuest Company       			http://www.forequest.com/

   "less is more."
		-- Mies van de Rohe.

   Ken Thompson has an automobile which he helped design.  Unlike most
   automobiles, it has neither speedometer, nor gas gage, nor any of the
   numerous idiot lights which plague the modern driver.  Rather, if the
   driver makes any mistake, a giant "?" lights up in the center of the
   dashboard.  "The experienced driver", he says, "will usually know
   what's wrong."

		-- 'fortune` output

-----BEGIN PGP SIGNATURE-----
Version: 2.6.2

iQCVAwUBMgpmWy/fy+vkqMxNAQEZfQP8C69iVqCdXBudh8N2UIlLVew65Yi8lkad
Wjnsur/vsFbsGQZBOvh5IBshJkLBYPZPL2Q92Zi14Xcir8/Ld18N8kFShQ97id5l
npXMcY7ncFnfeohdwhIJdDgzaNYK9i/eVeb90JVPh/cV89xw9BnXv4h/7xW3ul+j
xp/m1oyRZ/w=
=Tsus
-----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE-----

On Fri, 9 Aug 1996 pgut001@cs.auckland.ac.nz wrote:

> Date: Fri, 9 Aug 1996 05:12:56 (NZST)
> From: pgut001@cs.auckland.ac.nz
> To: cypherpunks@toad.com
> Subject: An SSL implementation weakness?
> 
> The following weakness seems very obvious, I've got a partial writeup of this 
> but before I turn it into a paper or something and arrange a demonstration of 
> how it would work I thought I'd check to make sure (a) someone else hasn't 
> mentioned it before, and (b) it is actually possible (it seems too simple to 
> be true):
>  
> 1. Using DNS spoofing, stage a hostile takeover of an address (for example 
>    using bogus referrals set yourself up as the delegated server for a DNS 
>    subtree).
> 2. Get a Verisign certificate for an arbitrary company and set up a bogus site 
>    at the stolen address.
>  
> 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?
>  
> Peter.
> 

This certainly _looks_ like a viable hack on SSL...
of course, the other option is just hack Root on the _real_ server, and
steal their certificate (harder than I make it sound, but usually not to
complicated, assuming you can spoof IP and DNS, etc...)

 --Deviant
        "Evil does seek to maintain power by suppressing the truth."
        "Or by misleading the innocent."
                -- Spock and McCoy, "And The Children Shall Lead",
                   stardate 5029.5.


-----BEGIN PGP SIGNATURE-----
Version: 2.6.2

iQEVAwUBMgrEWzAJap8fyDMVAQFhUwf9EanUPzCVnp1rawVKucnuG78GvwpRNZzA
Pu1LXIpfiCZeIsDOsLUMEHoyhukYuxnO8sZOS4CJdifU7ibdyofhxyBrxB+xOmny
2bnqSmOKl7qFocFFIEPUj7byThp22X4ynGuqgv4iBLuL7h2gaOuF7iz1mxacU0AJ
7QDsyiUJV/0mCOZeO+KEre/TLnsWOqbL5GGnsjM6JZ12LsqFUmXwQySWOkywbisq
OFt6jxo2JlfLDm5+XXyN5VTnTEsub4q/qaTf2bu9FLUfSic73YzusMyK9mmZ7nwu
0XEeV7zooQ16tCwD9XS2eoVHmqmUzrxiypZcrSmf9MvCwzFgVGxyYQ==
=Ckhu
-----END PGP SIGNATURE-----

This was the second SSL problem documented; it was fixed in 
netscape 2.0. The fix is to include the hostnames used for the server in 
the certificate as multi-values for the CommonName (CN). 

The fix is relatively simple; The client must then check the certificate
to make sure the hostname matches, and the CA must not check ownership of
domain names before issuing certs. 

Simon
(the first, and silliest was the original SSL's habit of using RC4 on 
(essentially) known plain-text with no checksum. Doh!) 

 ---
Cause maybe  (maybe)		      | In my mind I'm going to Carolina
you're gonna be the one that saves me | - back in Chapel Hill May 16th.
And after all			      | Email address remains unchanged
You're my firewall -    	      | ........First in Usenet.........