1996-08-09 - Re: An SSL implementation weakness?

Header Data

From: The Deviant <deviant@pooh-corner.com>
To: pgut001@cs.auckland.ac.nz
Message Hash: d593f4c0249a1b605c06d5dbb6b92329e537e94aa9cc36f5a9aab6b53d25d97c
Message ID: <Pine.LNX.3.94.960809045202.653D-100000@switch.sp.org>
Reply To: <83952437618205@cs26.cs.auckland.ac.nz>
UTC Datetime: 1996-08-09 07:19:46 UTC
Raw Date: Fri, 9 Aug 1996 15:19:46 +0800

Raw message

From: The Deviant <deviant@pooh-corner.com>
Date: Fri, 9 Aug 1996 15:19:46 +0800
To: pgut001@cs.auckland.ac.nz
Subject: Re: An SSL implementation weakness?
In-Reply-To: <83952437618205@cs26.cs.auckland.ac.nz>
Message-ID: <Pine.LNX.3.94.960809045202.653D-100000@switch.sp.org>
MIME-Version: 1.0
Content-Type: text/plain


-----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-----






Thread