Re: Is SSL dead?

[Steven M. Bellovin]

In message <[EMAIL PROTECTED]>, Bill Stewart writes:
> At 04:35 PM 10/6/99 , Phillip Hallam-Baker wrote:
> 
> That means that you can only succeed against web-users whose browsers
> still accept SSL2.0, which is most Netscape users by default;
> I don't know if IE also defaults to that, but it probably does.
> Even if the https://www.target.com uses SSL3.0, the user isn't talking to it 
> -
> they're talking to https://www.attacker.com, which can use 2.0 if it wants.

Right -- and as long as sites like amazon.com -- to pick a real-world, 
just-verified example -- accept only SSL 2.0, asking folks to turn it off just 
isn't real.

--Steve Bellovin

Re: Is SSL dead?

[EKR]

Bill Stewart <[EMAIL PROTECTED]> writes:

> 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.
> 
> That means that you can only succeed against web-users whose browsers
> still accept SSL2.0, which is most Netscape users by default;
Actually, this really isn't an SSL version issue. Rather it's
an issue about how the browser checks the cert chain. I don't
know for certain, but I believe that Netscape and IE both check
the chain correctly both for SSLv2 and v3.

-- 
[Eric Rescorla   [EMAIL PROTECTED]]
  PureTLS - free SSLv3/TLS software for Java
http://www.rtfm.com/puretls/

RE: Is SSL dead?

[Bill Stewart]

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.

That means that you can only succeed against web-users whose browsers
still accept SSL2.0, which is most Netscape users by default;
I don't know if IE also defaults to that, but it probably does.
Even if the https://www.target.com uses SSL3.0, the user isn't talking to it -
they're talking to https://www.attacker.com, which can use 2.0 if it wants.

Thanks! 
Bill
Bill Stewart, [EMAIL PROTECTED]
PGP Fingerprint D454 E202 CBC8 40BF  3C85 B884 0ABE 4639

Re: Is SSL dead?

[Steve Reid]

On Wed, Oct 06, 1999 at 06:28:45PM -0700, Greg Broiles wrote:
> 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. 

I think you're missing the point of the article. The issue is, what
happens when the imposter site simply doesn't use SSL?

It looks perfectly normal, like the thousands of other sites out there
that don't use SSL.

The "Location:" field shows http instead of https. How many people
would think twice about seeing "http://" in the Location field?

The little lock icon in the lower left corner of Netscape stays
unlocked, like it does 99% of the time. You wouldn't notice unless
you're savvy and alert enough to specificly check for it.

The only warning message that might appear is the "You are submitting
a form insecurely" dialog. But with all of the web forms out there
(search engines, web-based email, useless chrome, etc) that dialog is
quickly disabled on many systems- I'd bet nearly all of them.

No warnings about certificates because there just aren't any
certificates to warn about.

Anybody who doesn't make a point of ritualisticly checking security
information would likely be taken in.

RE: Is SSL dead? (was Re: ECARM NEWS for October 06,1999 Second Ed.)

[David Jablon]

At 07:35 PM 10/6/99 -0400, 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.

That's not the big issue here.  Server-spoofing is not fully prevented
by any version of SSL.  The problem is in how the typical user interacts
with the system.

There are many ways the user can be tricked by what he sees into
believing he is interacting with a trustworthy familiar site, when in
fact the site is a malicious imposter or site-in-the-middle.  Changing
the DNS binding is certainly not the only way to do it.

>The server certificate now binds the public key to a specific Web server
>address.
>
>   Phill

The point is that none of this binding matters if the user doesn't know
if the Web server address is correct.  SSL alone just can't solve this
problem.

While you may not consider this to be "a problem with SSL", many people have
unrealistic expectations of what SSL or any similar cert-based protocol can
and cannot do.

>-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


David P. Jablon
[EMAIL PROTECTED]
www.IntegritySciences.com

Re: Is SSL dead? (was Re: ECARM NEWS for October 06,1999 Second Ed.)

[EKR]

"Phillip Hallam-Baker" <[EMAIL PROTECTED]> 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   [EMAIL PROTECTED]]
  PureTLS - free SSLv3/TLS software for Java
http://www.rtfm.com/puretls/

RE: Is SSL dead?

[John R Levine]

> 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.

It'd be pretty hard.  When I got a certficate from Thawte for a domain of
mine that hadn't existing until five minutes before I applied,
secure.services.net, they called me at the number on the WHOIS entry for
services.net to verify that it was indeed me applying. 

I suppose that a domain registered in a vanity registry that doesn't provide
meaningful WHOIS info, or if they used NSI's new web-based registry and
didn't give them a phone number, it's more likely that a CA could be tricked. 
But I can't have much sympathy there -- if you make it hard for people to get
in touch with you, you'll fail to hear from people you do want to hear from
as well as from people you don't. 

Regards,
John Levine, [EMAIL PROTECTED], Primary Perpetrator of "The Internet for Dummies",
Information Superhighwayman wanna-be, http://iecc.com/johnl, Sewer Commissioner
Finger for PGP key, f'print = 3A 5B D0 3F D9 A0 6A A4  2D AC 1E 9E A6 36 A3 47 

PS: Also, BIND 8.x is much harder to poison than older versions, since it 
doesn't accept glue records that don't relate to a request. 

RE: Is SSL dead? (was Re: ECARM NEWS for October 06,1999 Second Ed.)

[Phillip Hallam-Baker]

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 
The Internet Bearer Underwriting Corporation 
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".

RE: Is SSL dead?

[Greg Broiles]

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
> >ava