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 ?
Funny, I'd say the implementations are flawed and they're insecure. If the adhered to the RFC as it was written (rather than glossing over one little step), millions of users wouldn't be in a bind here.
That said, calling SSL insecure is about as sane as calling email insecure because flawed implementations are plagued with problems or http insecure because some web servers choke on archaic flags and such.
The moral of the story? Read your RFCs and then re-read them with a friend or two to make sure you read them right the first time.
Easy does it!
This comment has been submitted already, 276865 hours , 59 minutes ago. No need to try again.
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
I know.. At least those dirty GNU hippies got it right.
What? You say konqueror's affected?
Lets see how fast the KDE team fixes their software and how fast the Microsoft team fixes theirs. If its not already done that is.
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?
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.
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.
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.
Indeed, the site authentity thing is the way Verisign and friends get away with charging ridiculous amounts to spin off a key pair. I'm not saying that it's a useless service (it is nice to know that I'm talking with my bank versus the incredibly remote scenario that someone hijacked their domain), however that feature is pretty low on most people's importance list.
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
That doesn't fix the problem. You're not testing it correctly, contact me offline if you want to do some actual testing.
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
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.
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.
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.
Funny that this comes out just over a week after Win2kSP3 is released....
First it has to be programmed, you are inside the whole fixing process, maybe this is new to you.
The fix is programmed now, this means that for example Red Hat must now release a security fix for its users, the users could get the fix using the normal update feature of there distribution.