"Steven M. Bellovin" <[EMAIL PROTECTED]> writes:
> The L0pht has issued a new advisory for an routing-type attack that can,
> they say, allow for man-in-the-middle attacks against SSL-protected sessions
> (http://www.l0pht.com/advisories/rdp.txt).
>
> The implication -- that there's a flaw in SSL -- is probably wrong. But
> they're dead-on right that there's a real risk of man-in-the-middle attacks,
> because the attacker can go around the crypto.
>
> By sending the proper ICMP packets to a vulnerable host (most Windows 95/98
> boxes, and some Solaris/SunOS systems), outbound traffic can be routed to an
> attacker's machine. This machine can pretend to be the destination of
> the SSL-protected call; it in turn calls the real destination.
>
> The obvious protection is for users to check the certificate. Most users, of
> course, don't even know what a certificate is, let alone what the grounds are
> for accepting one. It would also help if servers used client-side
> certificates for authentication, since the man-in-the-middle can't spoof
> the user's certificate. But almost no servers do that.
>
> This is why I wrote, a year ago, that we effectively have no PKI for the Web.
> It also underscores the importance of looking at the entire system design,
> rather than just the crypto. Crypto alone can't save the world; it's
> necessary, but far from sufficient.
For this to work requires more than the users to not check the certificate.
It requires them to deliberately ignore a warning from the browser.
To whit, if you attempt to connect to a site where the domain name
you enter in the URL does not match the certificate (i.e. the
Common Name), then Netscape brings up a dialog like:
The certificate that the site 'foo.bar.com' has presented does not
contain the correct site name. It is possible, though unlikely, that
someone may be trying to intercept your communication with this
site. If you suspect the certificate shown below does not belong to
the site you are connecting with, please cancel the connection and
notify the site administrator.
Now, I wish this were phrased more strongly, but I think it
makes the point fairly clearly.
At one point, IE wouldn't even give you the option of continuing
the connection. I'm not sure what it does now.
Now, this does require that the CAs that your browser trusts follow
the Common Name=domain name convention, but that's just a special
case of trusting your CAs.
Incidentally, the current HTTP/TLS draft (draft-ietf-tls-https-02.txt)
requires that the browser check the cert against the domain name
but provides a slightly more complicated check favoring subjectAltName
over CN.
-Ekr
--
[Eric Rescorla [EMAIL PROTECTED]]
PureTLS - free SSLv3/TLS software for Java
http://www.rtfm.com/puretls/
