Slashdot Mirror
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).
Has Slashdot become the comment board for The Reg articles ?
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 :-)
I do not deploy Linux. Ever.
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.
The opposite of progress is congress
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.
-
ping -f 255.255.255.255 # if only
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.
There's no place I can be, since I found Serenity.
Before the M$ vs Everyone war starts...how about we have a fair and simple timing contest.....where does this get fixed first? ;)
When in doubt, parenthesize. At the very least it will let some poor schmuck bounce on the % key in vi. (Larry Wall)
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.
Hey freaks: now you're ju
Somebody please turn this guy onto Mozilla 1.0!
One simple rule for its versus it's
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.
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.
Never underestimate the relief of true separation of Religion and State.
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.
Totally broken protocol from the end users' perspective.
sPh
> Man-in-the-middle attacks are very complex and
> not likely to be pulled off "in the wild".
No. MITM attacks are very easy to pull off with the right tools. You can easily take control of any TCP connection made by any other machine on the same Ethernet. Even if the network is fully switched you can use ARP poisoning to get around that.
Of course, if you manage to take control of a DNS server then you can easily do MITM attacks against many machines. Heck, do you trust the employees of your ISP with your banking information?
.. to a buried page on the guy's own site. This shows a little more detail on how to get a test setup running.
Alison
"It is a miracle that curiosity survives formal education." - Albert Einstein
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.
With this article from the Atlantic Monthly about Bruce Schneier and bad security.
Best Slashdot Co
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:
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.
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
Comment removed based on user account deletion
"I'm annoyed that browsers have been swept into warning you if the site you're visiting doesn't support Verisign's cash flow."
I know the feeling... the only other problem is, though, how does the vast consumer-base out there deal securely online? It doesn't add anything to have to phone up to read out an SSL certificate fingerprint - you might as well just place the order over the phone!
Maybe what we need is a kind of web-of-trust like the idea of a PGP key-server, only for SSL certificates?
~Tim
--
Rushing on down to the circle of the turn
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
Say no to software patents.
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.
11*43+456^2
By the way, I've performed full man-in-the-middle with a real bank
involved and myselft as victim. It's easy and works perfectly, so I've put
a brief description and screenshots at http://arch.ipsec.pl/inteligo.html
Details on programs' setup and fake certificate generation are omitted
not to provide script-kiddies with a ready recipe.
Actually, you can use Mike's https://www.thoughtcrime.org/ as demo
site but you first need to DNS spoof your browser into thinking
that www.amazon.com has address of 66.93.78.63, which is easy using
dnsspoof from dsniff for example.
From the SecurityFocus thread referenced in another post.
But will the KDE team have regression tested their fix?
There is no longer anything that can be done with computers that is nontrivial and clearly legal. -- Paul Phillips
Assuming the sources cited are accurate, we now have two independent misimplementations of SSL certificate handling, indicating that two purveyors of software that is entrusted with providing a secure (ie, private and authenticated) communications channel have screwed up in a way that suggests they did not understand properly what they were doing.
Rather puts buffer overflows into the shade, doesn't it?
As the late Professor Doctor Edsgar W. Dijkstra commented: "If you don't know what your program is supposed to do, you'd better not start writing it." RIP, a great man.
About 99.999%+ of the primary uses of SSL/TLS out there are for transport encryption, not for site authentity verification, and this does nothing to reduce the security of the transport encryption.
Umm. No. You are wrong. If you don't authenticate the person you are talking to, then you are vulnerable to a man-in-the-middle attack and the security of the transport encryption is nil.
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...
--
Time is on my side
By consulting with a mutually trusted third party, of course. A similar concept as that of a notary public. (I said similar, not identical).
Trust centers such as Verisign make it a little simpler to verify identity: I don't have to personally check you out myself -- I accept Verisign's "voucher" that you are who you say you are, and therefore I offload my research responsibilities onto Verisign.
This is not a perfect system for many reasons. But you can't HAVE a perfect secure system. I think this system is about the best we have for now.
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.
KMSMA (WWBD?)
Signed certificates simply state that Verisign trusts the company is who it says it is.
Other than take money do they do that much to establish that the company is who they say they are.
Anyway the certificate can say that the company is A and the webpage can say it's company B. If the certificate is okeyed by Verisign the user won't even see the certificate by default.
I tried the thoughtcrime.org test with the browsers I keep around under OS X. Here are my results:
Mozilla 1.0: passed (the others are right, the error message could be more user friendly, but it worked)
Chimera 0.4.0: failed (no SSL options in Preferences, also an early version without many features)
Omniweb 4.1 (v422): failed (SSL options in Preferences)
iCab Preview 2.8.1: failed (no SSL options in Preferences)
By "failed", I mean displayed the web page with no error messages (which I presume is the test). Some of those that failed don't appear to provide SSL support in the first place.
OmniWeb doesn't have much excuse though, it appears to have SSL support, and it is not a beta.
It's beginning to look like Mozilla is the only one on the ball here.
"What I'm thinking is different from what you are."
Belabera, "Mothra 3" 1998
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,
Hetz (Heunique)