This deserves further explanation. In order to begin an SSL session, the
server must present its public key and its site certificate to the client.
If the certificate has been signed by a trusted key (popular browsers ship
with many keys, held by CA's, pre-marked as trusted in the local key
database), it will be accepted if the domain name in the certificate
matches the domain name which presents the key. Some browsers support
"wildcard certs" which can be used for every machine in a domain - e.g.,
"www1.foobar.com", "www2.foobar.com", and so forth; while others want a
strict match on the fully qualified domain name.
If the server does not present a public key with a certificate signed by a
pre-trusted signer, the user will be prevented from visiting the site, or
will be able to click through a series of dialog boxes warning them that
they're accepting a certificate signed by a previously unknown signer,
depending on the browser and its configuration.
For the attack described earlier to succeed, one of two conditions must be
met - the hijacking site must get a certificate (which matches a
public/private keypair that it holds) signed by a pretrusted key, or the
user must agree to accept the certificate even though it's signed by an
unfamiliar signer.
How would a hijacking site get such a key? They could pay a CA for it,
perhaps by tricking the CA into issuing the key, or by modifying the local
software to insert their own key into the list of trusted keys. (It's
possible that browser publishers are using cryptographic techniques to make
the latter more difficult, but I have no idea whether they do or not.)
Whether or not the hijacker can succeed in tricking a CA into issuing a
cert wrongfully is a complicated question - it's probably (hopefully?) hard
to reach that goal if the domain name requested is a well-known one. If a
small business called "Mom's Diner" requests a key from CA 1 for
momsdiner.com, and a hijacker requests momsdiner.com from CA 2, it's
possible that CA 2 won't notice the overlap, or won't care, particularly
where both parties can reasonably justify their use of the name "Mom's
Diner", which isn't hard. Given the geographic diversity of CA's, it's
probably not hard to get a distant CA to issue a certificate that a local
CA would just laugh at.
Another attack might involve taking advantage of display versus core
abstraction - redirect the user to a site where the holder has requested a
certificate for their own domain name, so the underlying SSL code won't
sqwawk about a domain name/certificate mismatch, but use Javascript or
ActiveX to rewrite the portion of the display which indicates to the user
what site they're visiting. This way, the browser believes it's connecting
to "evilhijacker.com", gets a cert for "evilhijacker.com", and cheerfully
begins an SSL connection; but the user looking at the screen thinks they're
still talking to "bigcorp.com", sees the unbroken blue key, and cheerfully
hands over their credit card.
Contemporary browsers include multiple means of delivering the
site/certificate information, making it harder to perform this latter
attack, but they only work if people use them, and I don't think that most
people do.
Having said that, however, I think the first article was somewhat
irresponsible and underinformed, both with respect to SSL being "broken",
and with respect to there being no replacement in place. SSL is cheerfully
providing a secure connection, given all of the information available to it
- it's the wider environment (humans and DNS) that are allowing themselves
to be tricked. TLS (a replacement for SSL) has been available for over a
year now - while it's got its own problems (where it's incomplete, not
where it's insecure), it's old news by now, too.
At 04:35 PM 10/6/99 , Phillip Hallam-Baker wrote:
>This is a problem with SSL 2.0 first discovered by Simon Spero then at
>EIT.
>
>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.
>
> Phill
>
>-----Original Message-----
>From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of
>Robert Hettinga
>Sent: Wednesday, October 06, 1999 4:22 PM
>To: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]
>Subject: Is SSL dead? (was Re: ECARM NEWS for October 06,1999 Second
>Ed.)
>
>
>At 2:00 PM -0400 on 10/6/99, [EMAIL PROTECTED] wrote:
>
>
> > Title: Special Kurt's Closet: Is SSL dead?
> > Resource Type: News letter
> > Date: Semptember 30, 1999
> > Source: Security Portal
> > Author: Kurt Seifried
> > Keywords: INTERNET/WWW ,SECURITY ISSUES ,ONLINE SHOPPING ,SSL
> >
> > Abstract/Summary:
> > The title is a bit scary, but I wanted to get your attention
> >(worked, didn't it?). Most
> > security experts have been aware of problems with SSL, but
> >generally speaking we
> > haven't said much because there wasn't much of a replacement
> >available for it,
> > and it hasn't been exploited extensively (chances are it will be,
> >though). I'll start
> > with an explanation of the basic attack, followed by some methods
> >to protect yourself,
> > and finish with an interview with Dale Peterson of DigitalBond and
> >the summary.
> >
> > How to do it
> >
> > Let's say I want to scam people's credit card numbers, and don't
> >want to break into
> > a server. What if I could get people to come to me, and voluntarily
> >give me their
> > credit card numbers? Well, this is entirely too easy.
> >
> > I would start by setting up a web server, and copying a popular
> >site to it, say
> > www.some-online-store.com, time required to do this with a tool
> >such as wget is
> > around 20-30 minutes. I would then modify the forms used to submit
> >information
> > and make sure they pointed to my server, so I now have a copy of
> > www.some-online-store.com that looks and feels like the "real"
> >thing. Now, how do
> > I get people to come to it? Well I simply poison their DNS caches
> >with my information,
> > so instead of www.some-online-store.com pointing to 1.2.3.4, I
> >would point it to
> > my server at 5.6.7.8. Now when people go to
> >www.some-online-store.com they end
> > up at my site, which looks just like the real one.
> >
> > Original URL: http://securityportal.com/closet/closet19990930.html
> >
> > Added: Wed Oct 6 12:41:14 -040 1999
> > Contributed by: Keeffee
>
>-----------------
>Robert A. Hettinga <mailto: [EMAIL PROTECTED]>
>The Internet Bearer Underwriting Corporation <http://www.ibuc.com/>
>44 Farquhar Street, Boston, MA 02131 USA
>"... however it may deserve respect for its usefulness and antiquity,
>[predicting the end of the world] has not been found agreeable to
>experience." -- Edward Gibbon, 'Decline and Fall of the Roman Empire'
>
>For help on using this list (especially unsubscribing), send a message to
>"[EMAIL PROTECTED]" with one line of text: "help".
--
Greg Broiles
[EMAIL PROTECTED]
PGP: 0x26E4488C
