Follow Slashdot stories on Twitter

 



Forgot your password?
typodupeerror
Security Government The Internet United Kingdom IT Technology

Rogue SSL Certs Issued For CIA, MI6, Mossad 152

Posted by timothy
from the usual-suspectors dept.
Orome1 writes with this excerpt from Help Net Security: "The number of rogue SSL certificates issued by Dutch CA DigiNotar has ballooned from one to a couple dozen to over 250 to 531 in just a few days. As Jacob Appelbaum of the Tor project shared the full list of the rogue certificates, it became clear that fraudulent certificates for domains of a number of intelligence agencies from around the world were also issued during the CA's compromise — including the CIA, MI6 and Mossad. Additional targeted domains include Facebook, Yahoo!, Microsoft, Skype, Twitter, Tor, Wordpress and many others."
This discussion has been archived. No new comments can be posted.

Rogue SSL Certs Issued For CIA, MI6, Mossad

Comments Filter:
  • "*.*.com". I could really use a wildcard cert that wild...
    • Re:Wow... (Score:5, Interesting)

      by FriendlyLurker (50431) on Monday September 05, 2011 @01:18PM (#37309746)

      Related: Forget Rogue, Microsoft handed ability to intercept SSL on windows [google.com] (Another Wikileaks revelation [google.com], translated) to Tunisian dictator Ben Ali, apparently in return for contracts, stifling open source competition etc etc in Tunisia and allowing them to intercept Facebook, Google,... before the Arab spring revolution took place.

      • Ben Ali should ask for his money back.

      • Re:Wow... (Score:5, Interesting)

        by BCoates (512464) on Monday September 05, 2011 @04:21PM (#37310906)

        Not really. Any government can get their state CA included in the windows root CA list just for the asking. OSX and Firefox are slightly more restrictive, but not in a useful way, they allow lots of state CAs as well.

        This is a broad problem with the HTTPS system, too many unrestricted root CAs with no concern for realistic security scenarios.

        This is not a good system, but it has nothing to do with Tunisia. The wikileaks cable you posted doesn't even talk about SSL, just about how using supported Microsoft software in the government will make the government more effective at everything, including domestic espionage.

        • by initialE (758110)

          Any government can get their state CA included, but any user can have the CA revoked on their own computer. The problem with the intercept is that you can remove the CA, only to have it magically reappear upon visiting a site signed by their certificate.

      • ... im trying to google around a little bit to write one, but im frankly exhausted.

    • Re:Wow... (Score:5, Informative)

      by AVee (557523) <slashdot@aveBLUEe.org minus berry> on Monday September 05, 2011 @01:24PM (#37309794) Homepage
      And according to TrendMicro 'someone' make rather heavy use of the diginotar certificates on ~40 different networks in Iran: http://blog.trendmicro.com/diginotar-iranians-the-real-target [trendmicro.com]
    • by yakatz (1176317)
      Unfortunately (or fortunately, depending on your point of view), most browsers do not support nested-wildcard certificates.
      (I have tried it).
      The CA I usually use catches it and warns you, but some other CAs take your money and leave you with a mostly-useless certificate.
    • by Kalriath (849904)

      That doesn't even work, browsers would reject that as invalid.

  • It pisses me off how I have to jump through so many damn hoops only to get a false sense of security. We might as well go to using self signed certs as the norm for all the added security CAs give us.

    • by YesIAmAScript (886271) on Monday September 05, 2011 @01:03PM (#37309654)

      At least you know how many and which certs were issued from an authority that you run yourself.

      The chain of trust is only as strong as the weakest link in the chain.

      • by elsurexiste (1758620) on Monday September 05, 2011 @01:17PM (#37309744) Journal

        That may very well work for you or your organization. Not so much for third parties or the internet, which is the case here. I mean... would you trust a bank's homepage if it's self-signed?

        • by Zerth (26112) on Monday September 05, 2011 @01:21PM (#37309766)

          If I could pick up the cert from a local branch or by taking a picture of a barcode on the screen of an ATM, probably.

          • by Dahamma (304068)

            But that would basically limit all of your online transactions to businesses with a local office within driving range. Not many people are going to be willing to fly to Seattle just to get a cert to buy something online from Amazon...

            • Then you talk to a bank agent over they phone and they read you the fingerprint of the self-signed cert. You verify it and if you believe this person works for the bank, you're done.

              The problems with the system have been not within PKI, but the verification of trustworthiness. As a part of fixing this, each of us may have to work a little bit harder in order to establish that we trust a certificate. In fact many would say it is the unwillingness to make this effort that led us to this mess.

              • I would rather say we rely on CAs to avoid the hassle. If I trust "X", and "X" says I can trust "Y", that should be enough. I think dropping the hierarchical scheme and adopting a distributed scheme is better than individual verification (most people don't understand what is good for them anyways).
              • by Dahamma (304068)

                if you believe this person works for the bank, you're done.

                Which still means there is plenty of room for social engineering/hacking. It's still about trust, and talking to someone on the phone doesn't change that.

                It's debatable whether this would result in better or worse security, but it's not debatable that the costs in time and money over the current system would skyrocket. Every company on the planet wanting to do online transactions needing customer service reps available any time someone wants to v

        • by perlchild (582235)

          It's not havoc, it's just more work.
          Just revoke all the "root" certs in current use, and you're back to the basic:
          VERIFY (once, and then once they expire) every trusted cert you use, and sign them with your own key.
          Others in this thread mention validating the keys offline, which, for your bank, might make a lot more sense than trusting a third party.

          • by rtaylor (70602)

            How does manual verification help the bulk of the population identify fake certs?

        • by X.25 (255792)

          That may very well work for you or your organization. Not so much for third parties or the internet, which is the case here. I mean... would you trust a bank's homepage if it's self-signed?

          Yes, I would.

          If bank can safely keep my money, you don't think they can safely/securely deliver me their self-signed root certificate which I can import into the browser?

    • Extended validation certificates were definitely a step in the right direction, with a pretty green favicon background.
      But that wasn't enough. So we went to Ultra-yotta-analprobed-extented-validated-certificates with a plaid favicon background, thus fixing the problem forever.

  • Can we move on now? (Score:5, Interesting)

    by ka9dgx (72702) on Monday September 05, 2011 @01:02PM (#37309644) Homepage Journal

    We've now had proof positive that no centralized trust system is workable against a sustained attack. Can we start to get some distributed trust systems in place, instead? The idea of a single proof of identity has failed. It's time to move on to a system that allows multiple checks and balances.

    Monocultures are great for creating massive failures, which is why nature wipes them out over time.

    • Re: (Score:2, Interesting)

      by Anonymous Coward

      Delete all your root certs. Add sites on an individual basis.

    • by nweaver (113078) on Monday September 05, 2011 @01:12PM (#37309698) Homepage

      The root of the problem (pun intended) is NOT that the SSL/TLS certificate hierarchy is a centralized trust, but that there are hundreds of roots of trust, any one of which may be compromised, and all of which are considered equally valid by the browser.

      Who outside of the Netherlands even heard about DigiNotar before this happened?

      This is why some people like the idea of using DNSSEC for distributing key material: there exists only a single valid path of trust to a single root for a key associated with any given name: its actually more centralized than SSL/TLS, which is what is desired.

      • by mellon (7048) on Monday September 05, 2011 @01:18PM (#37309750) Homepage

        The trouble with this is that it makes the root cert *insanely* valuable if we start using it in the way you describe. As a practical matter, there needs to be some additional system in place to provide a backstop for the root, so that merely compromising the root is not enough to successfully spoof every domain. DNSSEC + SSL CA is actually not a bad idea. But I am really worried about the push to use DNSSEC as the new single point of failure.

      • by Sancho (17056) * on Monday September 05, 2011 @01:37PM (#37309880) Homepage

        its actually more centralized than SSL/TLS, which is what is desired

        Centralization only works if you place a high amount of trust in the central organization. Do you trust ICANN? Do you trust .us? .ir? .uk?

        The CA system is only broken because there are weak links. The client trusts 200 CAs, and any one of them can sign for any domain. But what if we required 2 CAs to agree? 5? 10? It would be up to the admins of the server to decide how many CAs they wanted to use, and users could decide for themselves how many are required to agree in order to consider the cert valid.

        Moxie Marlinspike has some other ideas that sound pretty neat. Unfortunately, at first glance, his techniques seem to also rely on SSL, creating a chicken-and-egg problem. I may have been misunderstanding him, though.

        • by AlXtreme (223728)

          But what if we required 2 CAs to agree? 5? 10? It would be up to the admins of the server to decide how many CAs they wanted to use, and users could decide for themselves how many are required to agree in order to consider the cert valid.

          Interesting, but all that would do is spur companies to automatically obtain multiple certificates from multiple CAs. If such a system were compromised we'd be in the same situation as now.

          Perhaps both avenues are required: Each CA may only service one tld (so a compromise

          • by Sancho (17056) *

            Good additions/modifications to the idea.

          • by Junta (36770)

            Interesting, but all that would do is spur companies to automatically obtain multiple certificates from multiple CAs. If such a system were compromised we'd be in the same situation as now.

            Uhh, no, a single CA being compromised would be meaningless, you'd have to compromise as many authorities as is required to trust a cert, and do so within a time period short enough to avoid at least one of those being revoked/removed from browsers.

          • by Lennie (16154)

            The current protocols, OCSP and CRL, don't even help to solve the CA-compromise problem.

            They don't even work properly to revoke just one certificate.

            There is a lot that needs to change and it needs to be backwardcompatible enough that a transition can be made.

            Which doesn't make it an easy task.

            But if you have a multi-CA system, you have to have a secure way to single the browser or other application how many that should be. How will you do that ?

            What if you have a website with 4 CA's, would that be good eno

      • by Junta (36770)

        : its actually more centralized than SSL/TLS, which is what is desired.

        The key is not the centralization or de-centralization (though a system without well-defined roots of trust or in which the end-user is responsible for tracking the validity of the roots of trust would be bad). The issue at hand is DNSSEC has no concept of validation beyond DNS cache lifetimes. If an authority key is compromised, then you push out your fixed keys and the threat ages out of the system in relatively short order. 100% OSCP with unforgiving clients would be the most trivial fix to this mess.

      • A better idea might be to segregate trust based on jurisdiction. We need to do away with the generic TLDs (.com. .net, .org, etc.) and use a national CA system in which a CA is only trusted for it's associated national TLD. Just a thought.
    • by Ken_g6 (775014)

      Can we start to get some distributed trust systems in place, instead?

      I suggest getting some Perspectives [mozilla.org] on the whole issue. Not only does it bypass warnings about self-signed certs, it gives an extra warning if a secure site looks hinky despite a valid cert.

    • by Junta (36770)

      The problem is not "centralized trust". The problem is a mix of x509 evolving but not mandating behavior (in the web context, CRL should be completely sunset and OSCP should be mandatory) and half-assing implementations today in the name of convenience (OSCP implementations are likely to ignore errors instead of failing validation, treating only an explicit 'invalid' as evidence of a problem. The root of the problem is a third party authority is used frequently without checking in with that authority. A

    • by guruevi (827432)

      The idea of identity on the Internet does not work. People have to stop using SSL certificates as a form of identity. They're there to secure a transaction. There are plenty of other ways even with valid certificates to trick a client (or end-user) into trusting a host (slightly different domain name, unicode tricks, ...).

      If you want to confirm identity between two parties you have to use 2 and 3-way, multi-channel authentication in both ways. That is more expensive than the current user-password and even u

  • Time to drop DigiNotar from trusted cert list?

    • by maxume (22995)

      Uh, it pretty much already happened.

      (That is, Microsoft, Google, Mozilla, etc., have dropped them, the various logistics are shaking out as we speak.)

      • I believe that's only for Vista+ -- XP would have to have a patch.

      • Uh, it pretty much already happened.

        (That is, Microsoft, Google, Mozilla, etc., have dropped them, the various logistics are shaking out as we speak.)

        Except... in the Netherlands, where DigiNotar is operating from. The government has demanded Microsoft in the Netherlands to delay the rollout of this patch, because it would cause too many problems for users, and because they need more time themselves to get all certificates replaced.

        Dutch article about this, including a link to the preliminary report about DigiNotar, here: http://tweakers.net/nieuws/76587/overheid-dwingt-bij-microsoft-vertraagde-windows.html [tweakers.net]

  • There is no reason for this company to keep operating after such gross negligence. Any criminal liability here?

  • by nweaver (113078) on Monday September 05, 2011 @01:08PM (#37309672) Homepage

    It may not be complete, but, F-secure has a list [f-secure.com] of the ones created, including *.*.com, *.*.org, www.cia.gov, addons.mozilla.org, *.torproject.org, etc...

    • by AVee (557523) <slashdot@aveBLUEe.org minus berry> on Monday September 05, 2011 @01:34PM (#37309864) Homepage
      I'm kind of perplexed by the *.*.com certificate, is there any use in having such a cert? Realistically there is no (legitimate) reason for such a certificate to exist. Is there any software around that will actually accept certificates which are that broad? I mean, if there ever is a clear giveaway for a MITM attack it would be a certificate like that.
      • There may be add-on for mozilla that supports wildcard certificates. And since addons.mozilla.org is associated with an alternative certificate, well...

      • by BZ (40346)

        > Is there any software around that will actually accept
        > certificates which are that broad?

        There has been in the past; those were considered bugs and fixed. But maybe some users are still running 6-year-old web browsers.

    • including *.*.com, *.*.org, www.cia.gov, addons.mozilla.org, *.torproject.org, etc...

      err.. forget all those. There's only one you need to know: www.update.microsoft.com

      Ownage.

  • by jeti (105266) on Monday September 05, 2011 @01:13PM (#37309710) Homepage

    You can't trust the root CAs. The whole infrastructure is broken and needs to be replaced with something else.

    For a start, webbrowsers should notify users if a certificate was replaced, even if the replacement is signed. And browsers shouldn't go into full panic mode over self-signed certs. They're still safer than using an unencrypted connection.

    • by mellon (7048)

      YES. User interface is at least as important as tech in security: if you have a bad UI, it doesn't matter how secure the infrastructure is, because people will use the bad UI to bypass it.

      There are some problems with self-signed certs, but they can be addressed by a better UI. You don't want users to get into the habit of clicking through self-signed certs. But an intelligently thought-ought security model here would be a huge win, because as you say, self-signed certs do add value, particularly in a

    • by xororand (860319) on Monday September 05, 2011 @03:34PM (#37310642)

      For a start, webbrowsers should notify users if a certificate was replaced, even if the replacement is signed.

      Certificate Patrol [mozilla.org] for Firefox.
      "This add-on reveals when certificates are updated, so you can ensure it was a legitimate change."
      The UI is good too. Certificate Patrol, along with NoScript and Cookie Monster [mozilla.org], is a major reason to use Firefox.

      X.509 handling is largely neglected by UI designers, not just in web browsers.
      Sometime clients actually have options like "[x] Accept all certificates".

    • by X.25 (255792)

      For a start, webbrowsers should notify users if a certificate was replaced, even if the replacement is signed. And browsers shouldn't go into full panic mode over self-signed certs. They're still safer than using an unencrypted connection.

      I wonder how many more years it will take until people start realizing that self-signed certs are MUCH safer.

      Sigh.

    • Absolutely true.

      We should have a hierarchy of different levels of trust. E.g. if my bank trusts a CA for credit card payments, I should be able to see in my browser that a secure Web site for payments is trusted by the payment trust chain. I will trust this site, because my bank trusted it (and will reimburse me, if the trust was not merited).
      For emails, e.g. I only trust my two email providers, and I got there certs pushed to my mobile phone for enhanced security.
      Etc.

      The whole "One CA is trusted for ever

  • the SSL industry is a nasty piece of work - typical extort-what-the-market-will-bear flavor of non-equilibrium capitalism.

    all DNS should be PK-signed and encrypted, and SSL should just use pubkeys found in DNS. a domain owner should be able to establish their own keys, signed by the domain key (which is in turn signed by their registrar as part of registration.)

    • This is capitalism. Digitnotar screws up so they won't be able to charge money anymore.

      What you've described is exactly what we have right now except for the pubkeys in DNS part.

      A domain owner does establish their own keys, you generate a key pair and send it to the registrar to be signed.

      The problem right now isn't lack of capitalism. It isn't that you can't establish your own key.

      The problem is that there 150 registrars you might trust to certify a site. One of them is valid and the other 149 are just opp

    • Trouble is, what semblence of decency the CAs possess is preserved largely because of the fact that there are so many, more or less completely interchangeable, competitors out there. As long as you don't want some gold-embossed-hologram-edition Verisign EV cert, you can always find some shoddy CA who is far more user-friendly than security would desire.

      The registrars, by contrast, are no less sleazy; but the more you reduce their interchangeability, in the pursuit of security, the less incentive they hav
  • Joke's on them since Facebook still doesn't support SSL!

    • by mellon (7048)

      Yeah it does. Go look at your account settings again. I've been using SSL on facebook for several months now.

  • ..that the Mossad has a website on the public Internet.

    Couldn't find Ziva's picture, though; I'm SO dissappointed!
  • by Anonymous Coward

    See this statement:
    http://www.4-traders.com/VASCO-DATA-SEC-USD-11275/news/VASCO-DATA-SEC-USD-VASCO-DigiNotar-Statement-13782237/

  • We're finally living in the future : "Iranian cyber-agents have compromised the secure communications link of Western Powers, partly as an effort to monitor activities of their own cyber-citizens and also as retaliation for an earlier Trojan horse computer virus attack which destroyed Iranian nuclear processing equipment".

    Flying cars and Linux on the desktop anytime now !

  • Presumably the Three Letter Agencies generate their own cert chains themselves, and employees manually confirm the fingerprints and tell their browsers to trust those custom certs? In other words, their internal sensitive data shouldn't be at risk of exposure due to the DigiNotar problems, because they'd be crazy to depend on a cert root that they didn't generate anyway. I can see how this whole fiasco might make a difference for some non-employee accessing a CIA (or whichever) web site, but other than th

    • The Three Letter Agencies generate their own cert chains themselves (except those outsourced by the Shiva program), and employees used to manually confirm the fingerprints and tell their browsers to trust those custom certs plus those of their Sri Lankan support agency; Chinese contractors and another 5375 certificates from old contracts that nobody can remember which ones matter any more? In other words, their internal sensitive data shouldn't be at greater than commercially acceptable risk of exposure due to the DigiNotar problems, because they'd have been be crazy to depend on a cert root that they didn't generate in the days when they could afford to spend time defending the USA and not just chasing down evil anti-globalisation and other protesters anyway whilst having to spend hours a day listening to whining from prisoners they're torturing. I can see how this whole fiasco might make a difference for some non-employee accessing a CIA (or whichever) web site, but other than that, it shouldn't be significant for the TLAs senior management... right?

      -Karl Fogel

      FTFY. Sorry about the loss of conciseness.

  • It's just a front end for their recruiting staff. They post wanted ads there - and then advertise the same ads in Israeli newspapers.

    • by PPH (736903)
      So when somebody applies for a job at Mossad, there's a change that they went in through a phony site that collects their identities before directing them to the legit job listings. The operators of that phony site now have a list of potential employees.
  • How centralized/decentralized the system is, isn't the problem. The problem is the lack of verification. Every one of the issuers is trusted to operate independently, with no overside or validation. What boggles my mind is that they are even able to issue certificates for domains that have already had certificates issued by someone else.

    I'm not surprised that that an issuer got hacked. The only unhackable computer is one that is shut off and physically disconnected from the electrical outlet (you can't

  • Alternatives (Score:4, Informative)

    by autocracy (192714) <slashdot2007@[ ] ... m ['sto' in gap]> on Monday September 05, 2011 @04:32PM (#37310974) Homepage

    There has been a lot of push at the recent DEFCON conferences, and associated conversation since, to look at alternatives to the current CA system. Moxie Marlinspike [twitter.com] has been pushing a remote-view notary system called which is currently a Firefox plug, and [convergence.io]Dan Kaminsky has been pushing for DNSSEC. [twitter.com]

    There has been an awful lot of discussion [stackexchange.com] about the technical details of SSL certificates on the Security StackExchange [stackexchange.com] (Stack Overflow cousin) website, including the related blog post I penned: A Risk-Based Look at Fixing the Certificate Authority Problem [blogoverflow.com].

  • On Diginotar's site you can barely tell anything happened, except for a small "security incident" press release.
    They are still trying to minimise it when it seems likely the whole company will be shut down for complete failure.
    Cowards.

  • Certificates serve two purposes:
    1. 2 Way Encription. (Security)
    2. Verifying the Site's (Identity).

    Microsoft and Mozilla's Brain dead Idea of putting HUGE warnings up for "Self Signed Certificates" means that people cannot just choose security. IMHO a certificates primary use.

    By using "Authority" signed Certificates people are "Trusting" someone else to secure their data. - and paying a large(ish) sum of money for this service.

    I would Prefer if every site had a self signed certificate. and a Separate n

Any given program, when running, is obsolete.

Working...