IE and Konqueror Bug Makes SSL Insecure

Spad writes "The Register reports that IE and Konqueror both have a bug that allows anyone with a legit Verisign SSL certificate to issue a 'legit' certificate for a 3rd party site. IE and Konqueror don't both to check the issuer of this intermediate cert making SSL in both browsers something of a joke". Update by Hetz: if you're using KDE from CVS, the fix is inside or you can wait to next week for KDE 3.0.3 (which will have more fixes for KDE 3.0). Thanks to Waldo bastian for the blazing fast fix (95 minutes since it was reported).

Comments

Sounds like a feature to me!

[Nonesuch]

I've been looking for a way to issue new "trusted" certificates for my web sites without having to pay big bucks to Verisign.

Little did I know, the answer was right in front of me, in the form of the one Verisign certificate I shelled out the cash for :-)

Re:What about Mozilla

[baldass_newbie]

From the article:
"Mozilla was not vulnerable, but I'm not sure if that's because it handled the situation properly, or is, ironically, somehow too buggy to be exploited."

I don't know if that's exactly a show of support. It goes into more depth if you'd bother to read the article.

Re:Huh?

[sporty]

Let's say I go to verisign and get a certificate for encryption, which also garantees my identity. With in the cert, is my information, encryption information, where the cert came from and who issued the cert. I can use my cert to generate other certs using encryption software.

What this means, for people who have browsers which don't check where the cert came from, will not be warned that a certificate was granted from an untrusted source. Who are trusted sources? AOL, Thawte, Verisign.. etc.. Look in browser prefs for certificate authorities; the trusted circle of people to say you are who you are.

Why is this dangerous? Well, for one, you can claim you are whomever you wish, while looking like you are from this trusted circle. You look like you are from this trusted circle because no one claims otherwise. Your browser would usually bitch at you about certs made from non-authorities. But since your browser won't bitch about where your cert came from, and just looks at the authority..

So what if it isn't from a trusted circle? Using this in combination with dns spooofing, you could get people to give you information over ssl "secure connection" (rolling eyes) without the browser bitching at you that the cert you are looking at was made by verisign but not issued by verisign.

Re:SSL is insecure?

[kasparov]

Since the title of the article is "IE and Konqueror bug makes SSL Insecure" and the article body says "IE and Konqueror don't both to check [sic] the issuer of this intermediate cert making SSL in both browsers something of a joke," then I would venture to say that they were not calling SSL in itself insecure. Let's try not to be nit-picky for the sake of being nit-picky.

So?

[dasmegabyte]

The certificate issuer is not exactly a secure concept anyway. The whole idea of "trusted providers" being a list of folks engineered by the browser's authors is just asking for trouble. Any of those companies can "go rogue" and start issuing free certs to anybody who asks, which one of them did a while back (then they succombed to the pressures and revoked all the rights, which was pretty crummy).

Besides, the contracts of all cert providers totally absolves them from any crime or misuse of data undertaken by their issued members. Which is a strange definition of "trust"...that it can only be placed in an unknown third party who has no control nor responsibility over the site you're connecting to, and neither has any liability should your data wind up in the hands of ne'erdowells.

Which is why I self sign everything. Since it all boils down to whether or not you trust me, why should I spend $150 trying to trick you into thinking I've passed some rigorous test for "trust". All that matters is that the data users send me is encrypted, which it is. That $150 cuts into my already wafer thin margins, and it cuts even more when you think I'll have to get a different sert for each of my subdomains.

Which is where this bug is actually beneficial. It allows you to get signed once for all your domain names. No more paying exorbitant sums for the paltry 10,000 cycles of processor time it takes to generate a certificate, you can get www.yourdomain as well as yourdomain, yourmisspelleddomain, secure.yourdoman and mail.yourdomain certified for the price of one. Just sign the main site...and use the money to buy an escrow insurance policy.

Re:So?

[mlong]

Which is why I self sign everything. Since it all boils down to whether or not you trust me, why should I spend $150 trying to trick you into thinking I've passed some rigorous test for "trust". All that matters is that the data users send me is encrypted, which it is. That $150 cuts into my already wafer thin margins, and it cuts even more when you think I'll have to get a different sert for each of my subdomains.

Unfortunately most clients/browsers seem to go out of their way to discourage self-signed certificates with error messages that sound like "This certificate was self-signed. We don't know who the hell this person is. They could be a terrorist wanting to destroy your computer. If you click YES then they could format your harddrive and steal your credit card. By the way, even if you click YES we'll keep asking you everytime you visit this site unless they shell out some $ to Verisign or Thawte"

Re:So?

[bwt]

Any of those companies can "go rogue" and start issuing free certs to anybody who asks, which one of them did a while back (then they succombed to the pressures and revoked all the rights, which was pretty crummy).

A certificate authority really is nothing different than a 3rd party who says "that certificate is legit". As you point out, anybody can be a certificate authority. However, I should be able to control who I think is a TRUSTED certificate authority, and the application should assure that I'm only told that certificate authority X certified certificate Y if that did in fact happen. If a CA goes "rogue", you can (and should) simply remove it from CA's that you trust.

This bug is much worse: IE appearently treats anyone certified by a CA as equivalent to that CA for certification of intermediates. Verisign certifies JohnDoe and then JohnDoe can transitively assert that Verisign certifies BadDude.

That is a disaster, because it means that in order to trust Verisign, you have to trust **everybody** that Verisign has ever certified, which is impossible.

Which is why I self sign everything. Since it all boils down to whether or not you trust me, why should I spend $150 trying to trick you into thinking I've passed some rigorous test for "trust".

Thats why I self-sign everything as you too :-] Seriously, though , there is nothing wrong with self-signing so long as there is an independent way to validate that you are who you say you are. For example, I work in a military environment and our cert admins hand walk certificates from them to you. Browsers generally come with the big CA's certificates built-in, so it's much easier to validate that Verisign is Verisign.

testing Moz 0.9.4 doesn't qualify as a test

[ChrisCampbell47]

Testing Moz 0.9.4 doesn't qualify as a test. Nor does slagging 0.9.4 bugs qualify as slagging Mozilla.

Somebody please turn this guy onto Mozilla 1.0!

Re:testing Moz 0.9.4 doesn't qualify as a test

[jslag]

I see; and testing IE5 and IE5.5 is different how?

Because, dear troll, Microsoft alleged at their respective release times that IE5 and 5.5 were 'release quality' software, while moz made it clear that 0.9.4 was still undergoing development.

Re:Spoof?

[gmack]

Don't be so sure about that. For the longest time windows allowed javascript to edit c:\windows\hosts (has the same affect)

Also the entire *point* of SSL certs is to make this sort of thing impossible. It should have popped up a warning telling the user that it wasn't the real certificate.

Check the SecurityFocus thread about this here

[Otis_INF]

http://online.securityfocus.com/archive/1/286893/2 002-08-05/2002-08-11/1 (opens in new window).

It seems that it isn't TOTALLY browser related. Verisign and Microsoft both know about this error, according to the people in the thread. It's a good read with a lot of detailed info about the flaw and where the flaw exactly is.

Re:Check the SecurityFocus thread about this here

[MSG]

Yes, it is totally browser related. The post that you refer to says that MS doesn't plan on fixing it, but not that it isn't their problem. The problem lies in their PKI implimentation, and regardless of their public face's claims of focus on security and trustworthy computing, they're continuing their old habits of not fixing problems until their customers force them to.

Damn.

[FreeLinux]

It's been 20 minutes now and KDE doesn't have the fix up yet.

This is just rediculous. Why are they taking so long? I don't have all day. ;)

Seriously though, with a long list of IE bugs still outstanding and Microsoft blaming Verisign, rather than fixing their software, I'll bet that KDE has a fix a month or more before MS.

Try it yourself right now ... here is what I saw:

[wherley]

If you hit the discoverer's web site using Mozilla 1.1b you get an -8183 error and it
will not display the page. Note this is not a complete spoofed-site demo unless you trick your DNS resolver into reporting his IP for www.amazon.com and pull up his page using SSL with that URL.

I would infer that Mozilla is correctly detecting the mistake in the certificate chain.

Notes on another practical demonstration of this bug are here.

Interesting resonance

[wiredog]

With this article from the Atlantic Monthly about Bruce Schneier and bad security.

Certificates aren't very effective to begin with

[defile]

Signed certificates simply state that Verisign trusts the company is who it says it is. That's about it. Signed certificates do not define whether your communications are encrypted or cleartext.

Signed certificates cannot prove that:

• The company you're purchasing from is trustworthy
• The certificate wasn't stolen
• Verisign wasn't tricked into signing the certificate (which has happened)
• An attacker hasn't redirected your connection to some other site from the backend (think PHP fopen())

Many companies don't bother with having their certificates signed. It's pricey, an administrative burden, and doesn't really increase security. I'm annoyed that browsers have been swept into warning you if the site you're visiting doesn't support Verisign's cash flow.

Re:Spoof?

[MikeBenham]

A lot of people have been saying that, so I wrote a tool (sslsniff) to demonstrate the problem in a more "real-world" setting. It performs undetected hijacking/sniffing of IE SSL sessions, even on a switched network. sslsniff: http://www.thoughtcrime.org/ie.html

Re:Huh?

[BlueUnderwear]

Still, with checking in place, I can just go to verisign, get me a cert.

You'll get an "end-entity" certificate earmarked for your own website (you have to prove you're in charge of the URL that you are getting a certificate for). The certificate won't work on other sites (because the browser compares the site's URL with the URL embedded in the certificate),...

Start producing certs

... nor can it be use to produce other certificates. Indeed, a non-buggy browser only accepts certificates with the "CA basic constraint" set to true for creating other certificates. And the CA won't hand out any such certificates, except to other reputable CA's.

Overall Impact

[photon317]

Please beware that the overall impact of this problem is relatively minimal. The sky isn't falling. What this allows is a man-in-the-middle attack without the usual telltale browser confirmation box that one sees when using an unsigned certificate. The attacker still has to get on the network between you and the website and essentially transparent-proxy your connection through a rogue ssl proxy to make this all work. For the most part people with this level of network access for wide numbers of people are not so devious as to actually do this for profit.

On another note - if they did a traditional man-in-the-middle SSL attack, it might be very hard to track down who did it, but it would be very easy to tell it was being done (because you'd get a browser warning about the certificate not being vaild for this site and/or signed properly). With this new approach, you get no browser warning, but it's presumably easy to track down the culprit, since the certificate signing chain will include a legitimate cert issued to the attacker that can be queried at Verisign or whoever they used - unless they steal a cert from someone else.

Re:Incident response? Let the race begin!

[tshak]

But will the KDE team have regression tested their fix?

Re:Take that B of A!

[TeddyR]

One bank security official once told me unofficially wrt that is that the bank does not like the fact that the source is availible. To them, this means that anyone can compile the browser and "take out" some of the features that make the browser secure. Or trojan it to make an SSL connection, get the username/password, and dump it to a text file or send it remotely.

With the older closed browsers there is supposedly a much smaller chance of that happening.

Try Opera... Some of them disallow NS6, but allow opera...

Re:Try it yourself right now ... here is what I sa

[karmawarrior]

Wrong error. The bug here is not that a website is saying it's X when in fact it's Y, it's saying that it's X and saying Z has said it's X and Z hasn't. So I assume what's happened is you typed in "thoughtcrime.org" into your browser, it identified itself as "amazon.com" and you got the error you're describing.

Now, do the spoof as he suggests. Edit your hosts file so that www.amazon.com has www.thoughtcrime.org's IP address, ie put in the line: 66.93.78.63 www.amazon.com into your hosts file. Where that file is depends on your system; in Unix it's in /etc, in Windows 9x it's in C:\WINDOWS (or whatever %WINDIR% is), in Windows NT it's something like C:\WINNT\System32\Drivers\etc. It's a plain text file. To confirm you've set it up right, type "ping www.amazon.com" afterwards, if it's pinging 66.93.78.63 then you're all set.

Now open your browser, and go to https://www.amazon.com/. If you don't get an error, your browser is vulnerable.

Re:Well I see /. says a "fix" is available now...

[HeUnique]

Well, the issue has been known to Waldo Bastian for the last 2 days and he fixed in on both KDE HEAD and KDE 3.0.x branch, and he's now fixing the KDE 2.2.2 branch (for people who preffer to stay with KDE 2.2.x yet).

The patch HAS been tested in the last 2 days, but it took 95 minutes to post a fix since the story was released..

Thanks,