Follow Slashdot blog updates by subscribing to our blog RSS feed

 


Forgot your password?
Close
typodupeerror
×
Security

IE and Konqueror Bug Makes SSL Insecure 452

Posted by CmdrTaco from the well-doesn't-that-suck dept.
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).
This discussion has been archived. No new comments can be posted.

IE and Konqueror Bug Makes SSL Insecure More

IE and Konqueror Bug Makes SSL Insecure

Comments Filter:

  • Heh (Score:3, Insightful)

    by kraf ( 450958 ) on Monday August 12, 2002 @09:45AM (#4054010)
    Has Slashdot become the comment board for The Reg articles ?

  • Sounds like a feature to me! (Score:4, Funny)

    by Nonesuch ( 90847 ) on Monday August 12, 2002 @09:45AM (#4054011) Homepage Journal
    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 :-)

  • Security. (Score:2, Funny)

    by saintlupus ( 227599 )
    making SSL in both browsers something of a joke.

    And here I was assuming that a fine MS product like Internet Explorer would embody the rock-solid security I've come to expect from the fellows in Redmond.

    For shame, for shame.

    --saint

  • After all, Konqueror is clearly a clone of IE (think about it: explorer vs. conqueror, both are file-managers cum web browsers, etc.). This is just a demonstration of how well the KDE people can emulate MS.

  • Start Timing... (Score:3, Insightful)

    by Vengie ( 533896 ) on Monday August 12, 2002 @09:54AM (#4054084)
    Before the M$ vs Everyone war starts...how about we have a fair and simple timing contest.....where does this get fixed first? ;)
    • OSS will always win. This is because there is no testing policy. If MS releases a Windows Update that crashes computers they look horrible. If you download a Beta or Alpha patch and it breaks something, you just shrug and go back to the earlier version. Personally, we just have to wait to see who releases a fully tested (regression, functional, etc.) patch first. This is much harder to quantify.

  • So? (Score:5, Insightful)

    by dasmegabyte ( 267018 ) <das@OHNOWHATSTHISdasmegabyte.org> on Monday August 12, 2002 @09:54AM (#4054085) Homepage Journal
    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? (Score:5, Insightful)

      by mlong ( 160620 ) on Monday August 12, 2002 @10:01AM (#4054146)
      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? (Score:2)

        by mpe ( 36238 )
        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.

        Thing is that having an "official" certificate dosn't prove much anyway. Other than that someone had given money to Verisign. I'm sure people here can say exactly what checks Verisign carries out.
        In strict terms this probably isn't even a bug, since it's just following a "web of trust" approach.
        • As far as verisign is concerned how trustworthy you are depends on how much money you want to give them. By means of a sliding scale of fees (bribes) you can get anything from a personal certificate right through to a CA certificate.

          Proof of the lack of checking being done is that fact that not too long ago somebody managed to by certificates that proved they were Microsoft when they weren't.

    • Re:So? (Score:3, Interesting)

      by topham ( 32406 )
      While I agree with you as to the actual effectiveness I don't think self-signing is actually a solution.

      I know that Verisign is less than absolutly trust worthy. I also know they take atleast basic steps to ensure they issue a certificate to the correct entity. (Yes, they have made mistakes on that in the past, re: Microsoft).

      I don't on the other hand, have any reason to believe you aren't a fly-by-night huckster waiting to receive a dozen (or thousand...) credit card numbers...

      I want some level of assurance that you are indeed traceable. Even if, to some degree, its a false hope. Even if you pull off a scam on Verisign (or any other registrar) I know that there is a much larger trail to trace back to you and that it is more likely to get a good response from law enforcement authorities and/or financial institutions.

      On the other hand, I've never concerned myself much with running programs which were self-signed. I mean, heck, I've run unknown programs on my computer since 1988, whats a few 'self-signed' programs...

    • Self-signing doesn't fix the problem. Instead of the it being signed by one mysterious party who nobody knows, it's signed by some other mysterious party who nobody knows.

      A Web-of-Trust is the only way to really have much confidence that you're not being Man in the Middled.

      Or to put it another way: SSL sucks, PGP rules.

      • A [PGP/GNUPG style] Web-of-Trust is the only way to really have much confidence that you're not being Man in the Middled.

        I understand the advantages of PGP's model over SSL's, but under PGP's model, how do I get my key signed by somebody who does not live within a few kilometers of my residence? How do I, an individual who wants to send and receive secrets to another party who lives on another continent, establish a chain of key signatures from myself to the other party?

        • What you have is a statistical sampling of the
          judgements of consumers of that key. Really,
          a chain of trust is a silly idea anyhow, because
          trust is modal. I may trust you not to cheat me,
          but that does not mean that I trust everyone you
          introduce to me not to cheat me. That's how
          venereal diseases spread.

          When we have a global relation store built on hash
          circles, then you can fetch a record of all the
          people who will rate a key, what modality they
          are rating it in, and how they rate it.
          As a result, you will be able to model their
          likelihood of default in all well-defined
          modalities, if the sample is large enough.

          I sign the keys of people I know by phone, or
          interact with entirely online on an ongoing basis.
          I don't see what distance has to do with it.

          • I sign the keys of people I know by phone, or interact with entirely online on an ongoing basis.

            I understand how it would work by telephone (read the hex digits of the fingerprint) because the public telephone system is a reasonably secure system, but I don't see how it could work for signing a public key you see on somebody's web site. How do you know the connection over which your online buddy sends her key isn't tampered somewhere between her computer and yours?

    • You don't get it (Score:3, Insightful)

      by pclminion ( 145572 )
      Sure, it boils down to whether or not I can trust you. But how do I know that your signature is *your* signature?

      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.

    • Re:So? (Score:2)

      by Fjord ( 99230 )
      The reason this is a problem is because certification is there to prevent man-in-the-middle attacks. If I can issue a cert that IE and Konq believe are for your site, then I can sit between your site and your clients and listen in on the conversation by taking what you say, intercepting it, reencoding it to my key and then taking what the clients say, intecepting it and reencoding it to your key.

      Self signing is a terribly bad idea because a man in the middle can always intercept your authority key and replace it with his own. This can happen too when you used standard keys, like Verisign, and download your browser on the web but it is less likely and you can check Versign's local public key in many ways to reduce the change you are being spoofed to near 0. Every encryption system in existance involves an inital trusted event, but I don't want to have to have an initial trusted even with each site I want to do business with.

      Still, for simple crap (e.g. anonymous message boards), self signig is probably ok by me. I just wouldn't bank or purchase with it.

    • Re:So? (Score:5, Interesting)

      by bwt ( 68845 ) on Monday August 12, 2002 @12:39PM (#4055359)
      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.

  • funny... (Score:2, Interesting)

    by Ender Ryan ( 79406 )
    Just this weekend my fiancee was trying to pay her credit card bill online. However, the bank's site wouldn't allow any browser other than IE into their site to pay. So she used Opera and masqueraded as IE.

    So, why on earth would a bank, or all companies, only allow what is probably the most insecure browser around to access the site? A bank for cryin out loud! A company that people trust to handle their hard earned cash, allows only IE to handle "secure" transactions on their site!

    And don't get me started on payment processing companies partnering with MS to develop secure payment solutions... You'd think they'd partner with IBM or any other company with a decent track record of reasonable security.

    • Probably because the bank is using a 3rd party to perform the encryption and send the transaction to their database. Why require IE? Why not? Who's going to complain?
    • Well, my employer has the exact opposite at his bank. He tried to login with IE and the banks website said that they do not trust his browser and suggested that he use Netscape 4.7

      Well, since he was running OS X I told him to try it with Mozilla and alas, it worked flawlessly.

      We both find it refreshing that at least one online banking system sees IE for the POS that it is.
      • What bank is this? Banning 95% of your customers from your site sounds like the kind of business plan a dot.com business would promote...

  • testing Moz 0.9.4 doesn't qualify as a test (Score:4, Informative)

    by ChrisCampbell47 ( 181542 ) on Monday August 12, 2002 @09:59AM (#4054129)
    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!

  • 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.

  • Interesting page (Score:2, Interesting)

    by PacoSuarez ( 530275 )
    Take a look here [e-matters.de]. I specially like the last paragraph about "reimplementing" the bug.

  • Check the SecurityFocus thread about this here (Score:5, Informative)

    by Otis_INF ( 130595 ) on Monday August 12, 2002 @10:06AM (#4054167) Homepage
    http://online.securityfocus.com/archive/1/286893/2 002-08-05/2002-08-11/1 [securityfocus.com] (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 (Score:5, Insightful)

      by MSG ( 12810 ) on Monday August 12, 2002 @10:25AM (#4054289)
      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. (Score:5, Funny)

    by FreeLinux ( 555387 ) on Monday August 12, 2002 @10:07AM (#4054176)
    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.

  • 'nother link (Score:3, Informative)

    by Draoi ( 99421 ) <<moc.cam> <ta> <thcoiard>> on Monday August 12, 2002 @10:18AM (#4054244)
    .. to a buried page on the guy's own site [thoughtcrime.org]. This shows a little more detail on how to get a test setup running.
  • The real insecurity is that they trust Verisign by default.

    -Adam

  • Interesting resonance (Score:5, Informative)

    by wiredog ( 43288 ) on Monday August 12, 2002 @10:22AM (#4054264) Journal
    With this article [theatlantic.com] from the Atlantic Monthly about Bruce Schneier and bad security.
  • Ok, who stole code from who?

  • Certificates aren't very effective to begin with (Score:4, Insightful)

    by defile ( 1059 ) on Monday August 12, 2002 @10:28AM (#4054299) Homepage Journal

    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.

    • "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?
    • Don't forget that the certificates cannot control the data once it's been uploaded to the server. How many attacks have their been where the DNS was redirected to a false server compared to how many have there been where the true server was compromised? SSL certificates are a solution to the wrong problem.
    • 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.
  • 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.
    • And the fact that the browsers come pre-loaded with certificates from the big players, and throw up a big FUD dialog box that implies to a non-technical user that their communications are somehow insecure is basically a protection racket. "Sure, you can self-sign, but your users will be calling your technical support desk and may be a bit worried about your security. Are you sure you don't want to use our services?"

    • 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.

  • Overall Impact (Score:4, Insightful)

    by photon317 ( 208409 ) on Monday August 12, 2002 @10:57AM (#4054456)

    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.
    • Oh yes, credit card thieves would never go so low as to steal a random certificate...

    • The last time my bank changed certificates, I called them up and had them read the fingerprint to me. Seems like a good thing to do, I figured. It was the first time anybody had called about that, but they did find it after half an hour on the phone, and the guy in the other end did understand the value of it. Really, I would like all their offices to have those fingerprints on paper, so I can go there and check.

  • This just makes three (Score:3, Interesting)

    by sirinek ( 41507 ) on Monday August 12, 2002 @11:08AM (#4054521) Homepage Journal
    Konqueror's javascript and DHTML support are "somewhat of a joke", so why not add SSL to that mix. :)

    I love KDE, but I will love it fully when I can stop having to load gnome-ish apps like Mozilla to cover up KDE's shortcomings.

    siri

  • A joke (Score:5, Funny)

    by Dirtside ( 91468 ) on Monday August 12, 2002 @11:13AM (#4054571) Journal
    making SSL in both browsers something of a joke.
    So, SSL, IE, and Konqueror walk into a bar...

  • This is truely wonderful - if lessons are learned. (Score:3, Insightful)

    by Observer ( 91365 ) on Monday August 12, 2002 @11:33AM (#4054750)
    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.

Slashdot Top Deals

Every program is a part of some other program, and rarely fits.

Close