[5852] in cryptography@c2.net mail archive
Re: Is SSL dead? (was Re: ECARM NEWS for October 06,1999 Second Ed.)
daemon@ATHENA.MIT.EDU (EKR)
Thu Oct 7 15:31:40 1999
To: "Phillip Hallam-Baker" <hallam@ai.mit.edu>
Cc: "Robert Hettinga" <rah@shipwright.com>, <dcsb@ai.mit.edu>,
<cypherpunks@cyberpass.net>, <cryptography@c2.net>
From: EKR <ekr@rtfm.com>
Mime-Version: 1.0 (generated by tm-edit 7.108)
Content-Type: text/plain; charset=US-ASCII
Date: 07 Oct 1999 08:12:33 -0700
In-Reply-To: "Phillip Hallam-Baker"'s message of "Wed, 6 Oct 1999 19:35:01 -0400"
Message-ID: <kjso3nxl0e.fsf@romeo.rtfm.com>
"Phillip Hallam-Baker" <hallam@ai.mit.edu> writes:
> This is a problem with SSL 2.0 first discovered by Simon Spero then at
> EIT.
Although Simon Spero did the first implementation of this attack, the
first writeup of it I ever saw was by Allan M. Schiffman (also at EIT)
about three months earlier. From the perspective of S-HTTP, this
attack is pretty obvious.
> It was fixed in SSL 3.0, that must be almost three years ago.
>
> The server certificate now binds the public key to a specific Web server
> address.
Exactly. See draft-ietf-tls-https-03.txt for a description of
how this is done.
That said, there's a more subtle version of this attack which SSL
can't defend against, even with this stronger binding. You attack the
transition from the insecure. Instead of poisoning the DNS, you simply
edit the URL as it comes across the wire in the last HTTP fetch.
So, when Amazon says "Click here (https://www.amazon.com/) to go
to our secure order site" the attacker replaces this with
https://www.attacker.com/. If the victim isn't paying attention
(they never do) this will work.
Incidentally, this sort of substitution is very hard to fix if victims
don't check identity. S-HTTP has the xsame problem, as did (I believe)
SET.
-Ekr
--
[Eric Rescorla ekr@rtfm.com]
PureTLS - free SSLv3/TLS software for Java
http://www.rtfm.com/puretls/
