Forgot your password?
typodupeerror
Security The Internet News

Phony Web Certs Issued For Google, Yahoo, Skype 151

Posted by samzenpus
from the bad-apples dept.
Gunkerty Jeb writes "A major issuer of secure socket layer (SSL) certificates acknowledged on Wednesday that it had issued 9 fraudulent SSL certificates to seven Web domains, including those for Google.com, Yahoo.com and Skype.com following a security compromise at an affiliate firm. The attack originated from an IP address in Iran, according to a statement from Comodo Inc."
This discussion has been archived. No new comments can be posted.

Phony Web Certs Issued For Google, Yahoo, Skype

Comments Filter:
  • by Anonymous Coward on Wednesday March 23, 2011 @04:26PM (#35591500)

    Comodo’s advisory:

    http://www.comodo.com/Comodo-Fraud-Incident-2011-03-23.html

    Firefox released 3.6.16 yesterday:

    http://www.mozilla.com/en-US/firefox/3.6.16/releasenotes/

    Microsoft released an advisory and patch yesterday:

    Advisory: http://www.microsoft.com/technet/security/advisory/2524375.mspx

    Patch: http://support.microsoft.com/kb/2524375

    • by blair1q (305137)

      Firefox released 3.6.16 yesterday:

      But did they already release 4.0.1?

    • by robmv (855035)

      If someone is trying to intercept your communications using a phony certificate, they already have access to your traffic, just blocking connections to those update sites and they will have those machines unpatched for a lot of time

      • The removal of the 'weaker' certs and authorities needs to be scriptable. Connecting to Mozilla updates is bad at the best of times - much much more so in countries where this incident might be more of an issue.

        From TFA:

        The Comodo breach will force organizations that might replace one or two certificates in a year to swap out nine certificates in a matter of hours - a painstaking and multi-step process that is often handled manually.

        Is there *anything* I can download - just a few Kb in size - to patch up my browser when cert issues arrive, rather than waiting for browsers to hard code the strings in 1-20Mb download?

        • Wait, what happens if when you go to mozilla.com to download an update, the cert for mozilla.com itself has been compromised?

    • Comodo knew about this on the 15th.

      Chromium was patched on the 16th/17th.

      Firefox was patched on the 17th,

      https://blog.torproject.org/category/tags/ssl-tls-ca-tor-certificates-torbrowser [torproject.org]

      Executive summary - SSL is broken as designed.

    • Does anyone have any idea how to update the CRL on a mobile phone, specifically, IOS?

  • Well (Score:2, Insightful)

    by The MAZZTer (911996)
    Time for major browsers to add that issuer to the blacklist, I guess. Or the individual certs, but that's less fun.
    • by poetmatt (793785)

      Uh, you're kinda behind. IE and Firefox have already been patched, no doubt chrome too.

    • by blair1q (305137)

      Ought to be a cut-and-paste operation, at worst. The issuer probably does it himself once he knows he's given out bad numbers.

      The question is whether blacklisting is really working on a lot of browsers on which cert checking is working.

    • by click2005 (921437) *

      I'd be interested to know if Comodo Inc uses SSL certs for it's own security software updates.

    • from Monday: Why Doesn't Every Website Use HTTPS? [slashdot.org] "HTTPS is more secure, so why isn't the Web using it?"

      Oh Irony!
      • by heypete (60671)

        Because an uncommon, widely-publicized, already-fixed incident that affects a very small number of sites is somehow worse than the status quo, where there's no validation of sites, no assurance of a lack of tampering of data in transit, or of illicit interception of data, right?

    • I said this wasn't over a few years after Verisign signed the fake Microsoft cert in 2001. http://www.cert.org/advisories/CA-2001-04.html [cert.org]

      I can't find my /. comment on it right now, as it was years ago, but everybody who responded said many checks had been put in place so that type of thing couldn't happen again.

      Well, I told you so. The problem is, it only takes one legitimate CA to screw up, and it subverts the entire system for all CAs.

      • Also given that we know how easy it is for goverments to coerce large buisnesses even in countries that supposedly have checks and balances you can basically assume that the goverment of any country with a recognised CA in it can get a cert to use to MITM your traffic.

        • Of course governments can get any certs they want. Using force to take what they want is their business. However, you have to consider the threat model. Governments are not after your bank account details (yours already has them and others have bigger fish to fry). You'd be a fool to rely on SSL to hide subversive activities but it's probably adequate for buying electronic toys from Amazon (or at least governments aren't the threat there).

    • One user account in one RA was compromised.
      The attacker created himself a new userID (with a new username and password) on the compromised user account.

      In lay terms, a sales rep login was compromised, and used to issue the certs. And we all know what sales guys are like, don't we [thewebsiteisdown.com]. ;-D

  • by oneiros27 (46144) on Wednesday March 23, 2011 @04:28PM (#35591530) Homepage

    The Mozilla Foundation, Microsoft, Google and other firms rushed out patches to their Web browsers on Tuesday to block the fraudulent SSL certificates. In an incident report filed on March 15, Comodo said the nine certificates were issued to seven domains, but that no attacks using the certificates had been seen in the wild.

    What, they don't support revocation lists already? This should be a non-issue, once someone realized it happened.

    • Re:Patches? (Score:5, Informative)

      by julesh (229690) on Wednesday March 23, 2011 @04:34PM (#35591600)

      What, they don't support revocation lists already?

      Firefox, to take an example, supports offline revocation lists (i.e. imported from files) or Online Certificate Status Protocol for automatically verifying certificates. Both of these are optional, although OCSP is enabled by default for certificates that specify an OCSP server in their details. Comodo do use OCSP, so this should be dealt with automatically for most firefox users. However, some may have disabled OCSP, and for these a CRL must be installed to revoke the certificates. The easiest way to persuade people to do this is by pushing a patch that contains it.

      • Why should we be trusting some dis-interested third party to give us that assurance? It's a loser's game! Certificate vendors are in a price war. They don't get paid extra for "going the mile" to confirm your identity, they get paid extra for processing more applications faster and charging 10% less than the other guy. The actual cost of the certificate is too cheap to measure - a couple of used PCs bought on Ebay and a free copy of Linux could probably satisfy most of the global need for certificates. The

        • by Lennie (16154)

          That is why people in the know say, EV-certificates (green bar, hopefully proper verification of organisation) is still useful.

          Yes I want DNSSEC, it will however take years.

          It is now slowly spreading over the TLD's, 20%of the TLD's now have or will soon have DNSSEC support. That 20% is the 20% of the most important/largest TLD's like .net and .com .org and .info So probably in practise more than 50% can soon be signed.

          The domainname providers and hosting providers are slowly starting to support it or have s

        • by Compaqt (1758360)

          Under DNSSEC, how do you verify the . root server (or other top-level servers: com, org, uk, us)?

    • Chrome does but that feature is off by default (perhaps it is slow?).
      • by heypete (60671)

        You sure? OCSP validation is a requirement for Extended Validation certificates. If OCSP is not enabled, the certs will still work, but they'll show up as ordinary SSL certs rather than the "green bar" EV certs.

        All major browsers have OCSP enabled by default.

    • What, they don't support revocation lists already? This should be a non-issue, once someone realized it happened.

      Yah, you get a new one in your browser patch. Those are manually distributed lists. You might be thinking OCSP. I think most browsers now do OCSP by default and have for a few years, and Comodo does support it so most people might already be set. This doesn't help all the weaker SSL clients out there, like what, almost every non-browser application using SSL.

    • To use a phony cert someone has to MITM you.

      And if they can MITM the SSL connection they can break the connection to the revocation list server. The browser treats this as a soft fail.

      https://blog.torproject.org/category/tags/ssl-tls-ca-tor-certificates-torbrowser [torproject.org]

  • CRLs? (Score:5, Insightful)

    by hawguy (1600213) on Wednesday March 23, 2011 @04:31PM (#35591576)

    The article says that browser makers rushed to put out patches to blacklist the fraudulent certs. Isn't this what certificate revocation lists [wikipedia.org] are for? Are CRLs completely broken and unused?

    • Re:CRLs? (Score:5, Informative)

      by Anonymous Coward on Wednesday March 23, 2011 @04:41PM (#35591698)

      Are CRLs completely broken and unused?

      Yes, they are. [imperialviolet.org]

      • by hey! (33014)

        Well, that's interesting, but not quite the same as saying that CRLs are broken. It just means you have to have reasonable expectations, which is where people often screw up. You can't expect a browser to check a certificate against a CRL if it can't access the CRL, but the when the browser *can* access the CRL it provides a useful service.

        If the browser can't reach the certificate server to check against the list, there's no ideal policy to choose. You don't want the certificate servers to be a single po

      • by evilviper (135110)

        No they aren't.

        Your article merely explains that CRL implementations are fail safe. A CRL isn't something that's needed 99.999% of the time, so depending on the CRL server being available would be a serious risk. Ignoring the CRL being unavailable is a good thing. A pop up warning would be unnecessary noise. The likelihood of an attacker getting a cert is remote, and being able to also block the CRL server is astronomically unlikely.

        • Your article merely explains that CRL implementations are fail safe.

          Safety is in the eye of the beholder.

          They're "fail safe" in the sense that you can still use SSL of the CRL server is down.

          They're "fail deadly" in the sense that if someone can MITM you to get you to use a phoney cert they can also break the connection to the CRL server.

    • Re: (Score:2, Informative)

      by BZ (40346)

      You may want to read http://www.imperialviolet.org/2011/03/18/revocation.html [imperialviolet.org]

      • A great article but the author does himself in with the final paragraph:

        A much better solution would be for certificates to only be valid for a few days and to forget about revocation altogether.

        As someone who spends a lot of time mixing with the 'enemies of the internet' - incl some dodgy states not listed, like India - I've learned to treat my browser downloading a new certificate as an *exceptional* circumstance - something to be looked into. Certificates should be worth something and they should be worth keeping a while. What's with the arbitrary validity anyway. Let the issuers choose the validity on a per-certificate basi

        • by BZ (40346)

          Actually, the author does address that. They key is that the private key would not change when the certificate changes. Unless the MiM has cracked the old cert (in which case you're screwed no matter what), they couldn't impersonate an update that keeps the same private key.

          • by jginspace (678908)

            Actually, the author does address that. They key is that the private key would not change when the certificate changes. Unless the MiM has cracked the old cert (in which case you're screwed no matter what), they couldn't impersonate an update that keeps the same private key.

            The two scenarios I'm thinking of when either: 1) a government, or 2) someone controlling you local network, manage to pass you fake certs. I can't say if the private key does or doesn't change in these two scenarios but the problem still remains - I'm being alerted to a certificate being renewed and I'm having to check up. You (or the author) don't address the 'whatcouldpossiblygowrong' or the 'escalation of cludginess' issues.

            • by BZ (40346)

              The only way to issue a cert with the same private key as another cert is to know that private key. If you know the private key and you know the certificate the server sends in response to an SSL request, then you can simply impersonate the server's existing certificate right now. In other words, a "certificate" is a pair consisting of a private key and the public bits that the SSL server puts on the wire when you connect to it. Everyone knows the latter, so "all" you need to MITM is to know the former.

              R

    • The article says that browser makers rushed to put out patches to blacklist the fraudulent certs. Isn't this what certificate revocation lists [wikipedia.org] are for? Are CRLs completely broken and unused?

      As a matter of fact, yes. SSL revocation mehcanisms are broken [imperialviolet.org] and nobody knew until a few days ago. Jacob Appelbaum wrote a nice write-up yesterday about how he noticed the emergency patches in Firefox and Chrome [torproject.org] regarding blacklisted SSL certificates.

  • no big deal (Score:4, Interesting)

    by Anonymous Coward on Wednesday March 23, 2011 @04:40PM (#35591676)

    Your browser already trusts a certificate authority run by the Chinese government, along with one that delegated authority to them.

    Your browser also trusts certificate authorities in Africa, *stan countries, and the non-EU portion of Eastern Europe. How many of these could be bribed or coerced if you knew the right people or worked for a random 3rd-world government?

    Really, the lock/key icon and colored URL box are totally misleading. You have almost no security. Given the rotten certificate authority situation, failing to accept self-signed and expired certificates is actually a loss for security. You might as well get encryption against a passive attacker. Pretending to be secure against active attackers is just providing a false sense of security.

    • by DarkOx (621550)

      Don't make statements about my browser, you know nothing about my browser. Yes I have actually removed most the Eastern Europe, Middle East, and China.

  • by Jah-Wren Ryel (80510) on Wednesday March 23, 2011 @05:01PM (#35591948)

    Neither of these are perfect, but here are two different firefox add-ons that can significantly reduce the chance of you falling victim to a compromised certificate authority:

    Network Notary [networknotary.org] - sort of crowd-sourcing approach
    Certificate Patrol [mozilla.org] - remembers the certs of sites you've visited in the past and tells you when they change

    • by jd (1658)

      There are a few add-ons for checking the strength of a cert as well - probably doesn't matter nearly as much, since the breach is through the vendor and not through a security hole, but it would not surprise me if there's a relationship between bargain-basement certs and bargain-basement security.

    • by caluml (551744)
      Ironically, addons.mozilla.org is one of the sites that had a fake cert generated for it.
  • by DriedClexler (814907) on Wednesday March 23, 2011 @05:18PM (#35592134)

    If I'm paying the CA to certify that public key X really is mine, and yet someone who's not me can get the same certification from the CA for being me ... what was I paying for again?

    RSA =/= rubber stamp authority

    • by dgatwood (11270)

      Well, ultimately, the flaw is that the CAs are allowed to deliberately conflate identity with encryption to boost sales. The fact is that 99.999% of sites do NOT need rigorous identity checks, but 100% of all websites SHOULD use encryption.

      In parallel with SSL, we should adopt a protocol similar to what SSH does, in which, upon connecting to a service, you decide if you trust it, and then your browser remembers the key fingerprint for that browser. This should not be in the form of a scary "this site may

      • by Sancho (17056) *

        The fact is that 99.999% of sites do NOT need rigorous identity checks, but 100% of all websites SHOULD use encryption.

        Fun with shell scripts: ShellScriptGames.com [shellscriptgames.com]

        FYI, your URL doesn't do https, and if I put https in front of it, I go to a different page.

        • by dgatwood (11270)

          Yup. That would be because my box hosts a couple of dozen domains, and SSL sucks at virtual hosting. If there were a solution for encryption that didn't involve your immortal soul every year for a multi-site cert, all my sites would be encrypted. Something like I suggested would completely solve that problem because you would be able to self-sign a single cert for multiple domains, and everyone's computer would simply remember that cert.

          The only options for me right now would be to either spend a fortune

          • by Sancho (17056) *

            But now you're falling into the same old trap--conflating identity with encryption.

            You can serve up any old cert for any old page. If identity doesn't matter, do it. The site is already broken with regard to identity (if I go to https://www.shellscriptgames.com/ [shellscriptgames.com] the page I get is actually https://www.gatwood.net/ [gatwood.net] but with https://www.shellscriptgames.com/ [shellscriptgames.com] shown in the URL bar.)

            I'm mostly just nitpicking because of the absolute (100%) you used. It reminds me of the occasional case of a Slashdot editor lam

          • by Sancho (17056) *

            Eh, I kinda just realized that I'm coming off like a jerk. Sorry for my comments.

      • This should not be in the form of a scary "this site may be masquerading as another site" dialog, but rather as a legitimate alternative that establishes encryption without establishing identity.

        The problem is that this does not ensure no one is eavesdropping. That is: how do you know that you're not actually connecting to an attacker that is relaying traffic between you and the real server? (i.e., a MITM [wikipedia.org]) The CA role in SSL exists specifically to prevent this sort of thing.

        In the case of SSH, to prevent this sort of thing you must check that the fingerprint you got matches the one you had previously obtained from the server (how often people do that is another story...) In the case of a web browse

      • by mvdwege (243851)

        The problem is that identity confirmation is innate in providing correct encryption.

        The problem is not the encryption per se, it is the key exchange. In order for Alice to securely talk to Bob, they have to agree on a shared secret to use for encryption. It is useless for Alice to provide Bob with a key unless she can verify she is not actually talking to Eve.

        Mart

      • by esarjeant (100503)

        This kind of scheme makes perfect sense to me. Then individual companies would become their own certificate authority and could self-sign as needed. As a consumer, the only decision I need to make is if I trust the destination and after doing this once I shouldn't need to do it again. Of course, as a company I won't have to keep shelling out pointless cash to a CA that doesn't really do anything for me.

        If my next visit to https://visa.com/ [visa.com] turns out to be a phishing site (don't bother following the link, it

    • by roman_mir (125474)

      Just look through this thread [slashdot.org] for all the fanboyism of the CAs.

      The argument comes up over and over again:

      Why are browsers treating self signed certificates over HTTPS as some sort of a plague, while not doing the same for HTTP?

      There is no difference between security of HTTP and HTTPS if the certificate is self signed, so just encrypt the traffic, DO NOT display the visual icon that signifies that the connection is secure and DO NOT bother the user with nonsense warnings.

      Better yet, display the fingerprint n

    • by Lennie (16154)

      Don't know.

      But you can go to https://www.startssl.com/ [startssl.com] and get the same 'domain-validation' service for free. :-)

  • I ask myself what would happen if the websites were small ones, do the issuer move that fast and browsers fix that fast too?

    I am not that sure. It is time that all CA must provide Certificate Revocation List and not be optional. Anye advantage of using a CA that provide it is nullified by the existence of CAs without CRL?

    • by heypete (60671)

      I ask myself what would happen if the websites were small ones, do the issuer move that fast and browsers fix that fast too?

      I am not that sure. It is time that all CA must provide Certificate Revocation List and not be optional. Anye advantage of using a CA that provide it is nullified by the existence of CAs without CRL?

      All CAs do provide CRLs, but it's enormously inefficient to provide the files to brazillions of end-users, as they need to download the entire files at regular intervals and likely don't visit more than a handful of sites that may be listed in the CRL. There's also a window in between when CRLs are published and when the user actually downloads the list, usually on the order of a week or so.

      Instead, most CAs and essentially all browsers support OCSP, which allows for live revocation checking. This has been

    • by Amouth (879122)

      i can say that they don't care about the smaller sites -- i revoked one of my certs just yesterday - (different reason still on a revocation list) and i'm sure it won't be put into any patch..

      as i always explain the costs for certs to the book keeper - just paying the extortion fee.

      • by Lennie (16154)

        Did you know that for every revoked certificate which makes it on the list it adds atleast a terabyte of traffic for the CA per year. That is just one cert.

        • by Amouth (879122)

          i'd love to see that backed up with real data..

          • by Lennie (16154)

            I guess I remembered it a bit wrong, it was a lot less. But still a lot:

            "How much costs ONE revocation? 0.2 KB x ~12,000,000 CRL downloads x 52 weeks x 7 years = More than 850 GB for ONE revocation."

            http://twitter.com/eddy_nigg/status/11729927248 [twitter.com]

            (Eddy Nigg owns/operates StartSSL)

            Maybe some other CA need get more requests (more sites using their certs ?) and maybe the numbers also go up in the years (more users)

            • by Lennie (16154)

              I think I just realized why this is.

              A CRL is a list of all the id's which have been revoked and the list as a whole is a re-signed/re-encoded everytime something is added, so the whole list is downloaded each time.

  • How dare they hack our computers!!! This isn't right! Someone should do something!! (I'm intentionally not going to reveal which country I'm from)
    • Totally different circumstances. In this case, Iran phishing for certs is a terrorist act. In the other, the Israelis and we were liberating the...uh...oppressed alpha and beta particles from your research facilities.

  • Don't they mean "The last proxy they were able to tracert to was in Iran"?
  • Google, yahoo, skype, they all have been compromised,
    I am glad I shut down my computer, and writing this with my pen and paper...

Please go away.

Working...