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).
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
No, if (shock) you had read the article, you would have seen that Mozilla (.94) is working fine and does not suffer from this problem. It has yet (IIRC) to be tested on newer versions, but they should still be fine...
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
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.
According to #kde on openproject.net, an uncommitted fix already exists for Konqueror. I'm sure more details will be posted when it has been tested and committed.
I've had Moz 1.1 complain about certificates where the cert company was inconsistent with the issuer.
if you install kde-bindings for konqueror when you install KDE then it uses the mozilla engine to render HTML/CSS/JavaScript etc. when you surf. however, i don't believe installing kde-bindings exempts konqueror from this problem - Security is handled in a separate module within the Control Center. anyone know otherwise?
when it rains, it gets real soggy. when it pours, i'm under the tap just _waiting_ for the joy
I read the whole article. His writing is atrocious. It doesnt't take much to be a "journalist" these days.
.. 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
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.
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.
Just tried it (opera 6.02/Linux) and it complains... asks whether you want to accept this dodgy certificate and gives you lots of info. So no, it's not vulnerable.
His post was simply a less direct method of the time-honored tradition of pointing out the horrendous spelling and editing to be found on a daily basis on Slashdot.
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.
That URL alone isn't a full demonstration. Your browser notified you of a problem because it thought the web site was www.amazon.com, and you typed in www.thoughtcrime.org. You have to edit your hosts file:
66.93.78.63 www.amazon.com
For the full effect.
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
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?)
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
According to the recent email to the kde-devel mail list, the fix for the SSL vulnerability is in KDE CVS and the stable KDE 3.0.x branch and will be part of the 3.0.3 release next week.
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)
And then wonder how long it will take Microsoft?
I hope Microsoft puts it through some sort of testing and Q/A process. 95 minutes to fix a serious security hole is stupid. You point out a problem with open source, lack of Q/A & testing, and hold it up like it is an advantage.
But then again, it took Mozilla how many years to but out the buggiest browser ever?