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