I haven't looked at the l0pht page yet, but you should be aware that the
browser checks the certificate so the user doesn't have to, under most
circumstances. The browser will display an alert if the hostname in the URL
doesn't matche the commonName in the certificate or if the certificate is
not issued by a trusted CA.
Thus, unless the man-in-the-middle can produce such a certificate, which
will require fooling a CA into giving him one, the client will not quietly
negotiate with him, believing they're talking to the end server. If he can
get such a certificate, that's an attack against the PKI, not the protocol.
Two significant dangers with SSL as deployed today:
1) The certificate is checked against the URL, so the security mechanism is
built upon the URL reflecting the user's intent. If the user doesn't display
the URL, doesn't check it, or is fooled by a plausible yet incorrect URL,
they will not be protected by the protocol or the PKI. (Note that this would
require the user to be directed to the bad URL, although that could probably
be done by modifying insecure web pages with links to secure ones.)
2) Most browsers extant do not check CRLs and most certificates don't have
CRL distribution point extensions, so certificates cannot, in practice, be
revoked.
Tim Dierks
VP of Engineering, Certicom
[EMAIL PROTECTED]
510.780.5409 [Hayward] -- 905.501.3791 [Mississauga]
> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On
> Behalf Of Steven M. Bellovin
> Sent: Friday, August 13, 1999 7:17 AM
> To: [EMAIL PROTECTED]
> Subject: going around the crypto
>
>
> 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.
>
>
>
