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.........
participants (5)
-
ichudov＠algebra.com -
Jeremey Barrett -
pgut001＠cs.auckland.ac.nz -
Simon Spero -
The Deviant