Follow Slashdot stories on Twitter

 


Forgot your password?
Close
typodupeerror
×
Privacy Security Your Rights Online

Are Some CAs Too Big To Fail? 163

Posted by samzenpus from the they-don't-fall-down dept.
Trailrunner7 writes "In the wake of this weekend's revelations of the seriousness of the attack on certificate authority DigiNotar, security experts have renewed criticism of the Internet's digital certificate infrastructure, with some wondering if larger certificate authorities (CAs) might be too big to fail. Would Mozilla and Microsoft and Google have revoked trust in root certificates from VeriSign or Thawte had they been compromised? Unlikely. 'It's not a simple matter of removing certificates from a database, because they're not in any databases,' says researcher Moxie Marlinspike, who presented an alternative approach to the current SSL infrastructure last month at DEFCON. 'We may never track them all down.'"
This discussion has been archived. No new comments can be posted.

Are Some CAs Too Big To Fail? More

Are Some CAs Too Big To Fail?

Comments Filter:

  • User ignorance (Score:4, Insightful)

    by betterunixthanunix ( 980855 ) on Wednesday September 07, 2011 @03:15PM (#37332094)
    Maybe we should do a better job of teaching people about computers and technology when they are in high school. CAs are able to get away with poor practices and poor security because most computer uses have no clue what a CA is. If people would start disabling Thawte's certificates en masse, Thawte would be forced to protect its business by regaining the users' trust.

    • Re:User ignorance (Score:4, Interesting)

      by jellomizer ( 103300 ) on Wednesday September 07, 2011 @03:25PM (#37332244)

      The problem with CAs are that they never really do their job quite well. If you are paying hundreds or thousands of dollars for a Cert they really should do a lot more work to verify who you are and the browser should identify the level of security the Cert gives.
      A cheap level (Under $50 per IP) for those B2B type of apps where you are connecting to a trusted source anyways but you don't want the error message or tell your customer to setup something new. A one note should suffice. Then you got a level good for online business (Under $500) this is for online stores, the CA needs to determine that it is a real store with the ability to sell the goods. However the browser should alert when ever there is a data stream that looks like a social security number or pushes a request for such non-merchant information. then you got the premium HIPAA level cert where it the CA needs to keep a close eye on its organization make sure the companies security is strong enough for the CERT this would be a full allow for the browser.

      • Re: (Score:3)

        by Bert64 ( 520050 )

        Self signed certs would probably be a better idea for businesses you already have a relationship with, like banks... You already have offline contact with the bank via mail or even walking into a branch, so they could use this to send you their certs and you won't have to trust anyone else.

        • Re: (Score:2)

          by tlhIngan ( 30335 )

          Self signed certs would probably be a better idea for businesses you already have a relationship with, like banks... You already have offline contact with the bank via mail or even walking into a branch, so they could use this to send you their certs and you won't have to trust anyone else.

          Why not have the bank be the CA for the businesses it does business with? That way, any business needing an SSL cert can go to their bank and get one. The bank's reputation is on the line and there's a definite trust enti

        • Not SELF SIGNS CERTS! I have seen the warnings in FireFox! SELF SIGNED CERTS will eat my babies, rape my dog, and make my hair fall out! Anything but that!


          Yes, this is sarcasm in that FireFox will go apeshit over a self signed cert, but pass all these fraudulent ones for months until people actually run the update.

        • Re: (Score:2)

          by heypete ( 60671 )

          CA-issued certs, even free ones from StartSSL and cheap ones from GoDaddy, have the advantage of being revocable. Nearly all the self-signed certs I've encountered lack a CRL or OCSP responder. This is a Bad Thing.

          • Re: (Score:2)

            by Lennie ( 16154 )

            An man-in-the-middle attacker can just drop the packets to the OCSP (do browsers by default even download any CRL's anyway ? usually they are just to large like 700MB+) it will timeout and the browser by default will just continue.

        • Re: (Score:2)

          by 0123456 ( 636235 )

          You already have offline contact with the bank via mail or even walking into a branch, so they could use this to send you their certs and you won't have to trust anyone else.

          I would totally, TOTALLY, trust a self-signed cert for my bank that turned up on a CD in my mailbox over one that was signed by a CA.

      • However the browser should alert when ever there is a data stream that looks like a social security number or pushes a request for such non-merchant information.

        I'd love to see you try to implement that...

      • Re: (Score:2)

        by pjt33 ( 739471 )

        Are you saying that you want browsers to only work to spec in the USA? Or are you expecting browser developers to have regexes for social security numbers in every country in the world, and to keep up-to-date with the legislation which is the closest local equivalent to HIPAA?

    • I'm highly doubtful of the efficacy of that. There are numerous business areas, even well-known names, who do just fine despite public opprobrium.

      A highschool course in IT taking down Thawte or forcing them to clean up their act would be about as likely as a highschool course in personal finance bringing down Goldman-Sachs or leading to the end of byzantine financial chicanery...

    • Oh yes, and while we're at it we'll teach them all how to fix a car so they can call out their mechanic if they recommend un-needed repairs, and teach them all construction so they can better review the work of the guy who builds their next home, and we'll put them all through medical school so they can better hold their doctors to best practices.

      Honestly, there's a point where you have to get off your high horse and realize that we have specializations for a reason, and it behooves those in the know on a g

    • Re: (Score:2)

      by rabtech ( 223758 )

      Any system that relies on users to know what is or isn't good is doomed to failure. Users don't check the address bar and don't know about certificates, nor should they.

      All too often their machines are 0wned already by malware and spyware, probably because they saw some cute puzzle game and just kept clicking OK at that damn dialog box getting in the way of playing my game!!!

    • Maybe we should do a better job of teaching people about computers and technology...

      Sorry, had to stop you right there, because the only thing that is ignorant here is thinking that users will actually learn to use the very device they rely on for damn near everything.

      Just saying, if users haven't learned by now, they won't. Period.

      And while we're on the topic of ignorance, can we please get the hell away from this "too big to fail" crap? Do images of the Titanic at the bottom of the sea paint enough of a picture? Does the word "Rome" ring a bell? I mean c'mon, seriously, let's at leas

      • The term 'too big to fail' doesn't refer to being unable to fail but rather, not being -allowed- to fail because the consequences of failure would be too catastrophic.

        • > The term 'too big to fail' doesn't refer to being unable to fail but rather, not being -allowed- to fail because the consequences of failure would be too catastrophic.

          Which is a bogus term. "too big to fail" = "the general population gets fucked with the bill"

          True Story:

          Forest Ranges used to be anal about stopping _every_ forest fire. They eventually learnt that this makes the situation _worse_ in the _long_ run because all the decay that _would_ of been cleared when a big fire hits, is still there.

          S

      • Re: (Score:2)

        by lennier ( 44736 )

        Do images of the Titanic at the bottom of the sea paint enough of a picture?

        As they say, sometimes failure isn't an option - it's mandatory.

  • Too big to fail... (Score:5, Insightful)

    by houstonbofh ( 602064 ) on Wednesday September 07, 2011 @03:19PM (#37332152)
    Too big to fail means too big to give a shit. Failure is the motivator for performance. With no cost for bad performance, there is no incentive for good. Just ask the "big" banks, or better yet, ask the customers...
    • Or our government, or better yet, ask the citizens.

      F and i thought i was a dem

      • Re: (Score:2, Insightful)

        by Anonymous Coward

        Both Democrats and Republicans (and even Tea Partiers, from what I've seen....) are for big government. The argument is what part of the government should be big.

        We compromise by making both sides big.

    • I'd say "Too big to fail := Too big to exist". ;)

  • I'm not too sure how CA's work, but if till this point we know, say "Thawte" is uncompromised.
    Then, secure Thawte, issue new certificates using a different name, say "Thawte2"

    Change this name every year or so, securing the previous certificates.

    This way, in case of a compromise, only a max. of 1 year of certs are invalidated

  • Marlinspike's approach (Score:5, Interesting)

    by AceJohnny ( 253840 ) <jlargentaye@gmai ... minus physicist> on Wednesday September 07, 2011 @03:29PM (#37332310) Journal

    Marlinspike's approach, implemented in a Firefox extension [convergence.io] presented at DefCon '11, is to do away with the notion of CAs altogether in SSL, replacing it with a distributed network that reports on the certificate they see. Basically, if the certificate you see agrees with the rest of the network, then you're not being spoofed.

    He had previously explained [thoughtcrime.org] the properties a replacement to the CA system had to demonstrate in order to be viable

    • Re: (Score:2)

      by vadim_t ( 324782 )

      How do you authenticate the authentication server?

      If I got it right, this system needs to contact some server that says "I cerfity this cert as valid, because the fingerprint was the same from the 50 different network paths we checked it". Ok.

      But, that message has to be transferred securely as well, otherwise Mallory just spoofs that server, and you've got no security. And you can't do the checks yourself because you don't have 50 servers around the world you can use for testing.

      • How do you authenticate the authentication server?

        You dont. You are the authentication server, and you ask 50 servers.

        • Re: (Score:2)

          by vadim_t ( 324782 )

          That's not very useful if your ISP is doing the MITM, which is very much a reality in many places right now.

          For instance, there have been several articles here on ISPs injecting content into the websites they serve.

          • No, if the ISP is doing MITM, they won't be MITM all those 50 too. So all you have to do is check those cert fingerprints to check the first connect for them.

            • Re: (Score:2)

              by vadim_t ( 324782 )

              How are you so sure of that? What would prevent it?

              They're in between you and those 50, they can spoof everything they like.

          • That's not very useful if your ISP is doing the MITM, which is very much a reality in many places right now.

            To add a notary you have to input the public cert for the notary, how do they MITM that without throwing warnings.

  • with Comodo, they only hardcoded some certificate signatures but did not revoke the entire CA. There is another problem: "your website is too small to care". I am not sure if a small business operator will receive the same treatment like they did with Comodo, patch their browsers to protect users of your small site

  • CAs should be limited to sets of domains, and this enforced in browsers. Country-level CAs should be limited to the country in which they operate. Government CAs should be limited to their domain (".gov", "mil.uk", etc.).

    CAs for the open domains should have to post a big bond, which can obtained through a bonding agency if necessary, with a value of at least $10 million, to back up their "relying party agreement".

    That's what "corporate responsibility" means - third party bonding.

    • Re: (Score:3)

      by vlm ( 69642 )

      CAs should be limited to sets of domains, and this enforced in browsers. Country-level CAs should be limited to the country in which they operate. Government CAs should be limited to their domain (".gov", "mil.uk", etc.).

      CAs for the open domains should have to post a big bond, which can obtained through a bonding agency if necessary, with a value of at least $10 million, to back up their "relying party agreement".

      That's what "corporate responsibility" means - third party bonding.

      Well, theres one thing I guarantee we are not going to do. Lets look at the american experience:

      1) I trust my employer to give me a job for life in return for my loyalty. Whoops
      2) I trust my bank to only loan me a mortgage I can pay off. Whoops
      3) I trust my health insurance company to be there for me when I'm sick. Whoops
      4) I trust my car insurance company to help me with my claim. Whoops.
      5) I trust my hardware store (and China) not to sell me poisonous drywall. Whoops.
      6) I trust my food store not to b

  • We regularly find Windows workstations that won't accept a valid certificate from any of several known good servers one of our applications use. Sometimes installing the root certificate solves it, but often it doesn't. Most of the time reinstalling Windows is the only solution.

    Microsoft is of no use in these circumstances, as they avoid dealing with root certs at all. The CA also has no answer. Applying root updates, the specific certs, an all-encompassing cert, even removing and reapplying the CA in W

    • This isn't related to an intermediate CA issue, is it?

      For example, Entrust, as part of the switch to 2048-bit certs, starting using an Entrust L1C chain authority - and we've had to load that L1C intermediate certificate onto servers to get them to recognize the certs that Entrust issued. Until you load them, the UI is not terribly helpful - the certificate chain tab doesn't show the missing L1C certificate.

      • One set of certs are Equifax, the other from GTE Cybertrust. Both have troubles.

        • Re: (Score:2)

          by Lennie ( 16154 )

          You don't by any chance have connection problems to Microsoft ?

          As Windows comes with only a few root certs by default, the rest is checked on first-contact by contacting Microsoft to see if they think it is a good CA.

          Even if the user has no administrator rights, it will still install the CA-root certificate on the machine-account.

          • This problem affects >40 of our users. It's not me. Our application uses Windows and OpenSSL. The network traces are definitive.

          • And no, we are unaware of connection problems to Microsoft. We see good Windows Update sessions, we can download the rootsupd.exe when we ask for it, and we do NOT see any network call to Microsoft in response to the failed attempt.

            I'm not professing to be an SSL expert, I just know what I see, and we see problems getting root certificates installed correctly and working, and there is literally NO help from MS or the CAs. MS is mute on the subject, even abandoning a support call without explanation.

            My sus

  • Too big to fail.... Just a sign of the times I guess. Don't expect anything to get better if this is the question we ask ourselves.

    • Re: (Score:2)

      by Rich0 ( 548339 )

      Yup, in my book too big to fail is too big to exist.

      When something too big to fail does fail, the solution should be a government takeover for the public interest. The government keeps the operation running, dives through the records for evidence, and then files criminal charges against the former management and sues them for damages.

      The too-big organization is then chopped up into manageable pieces and they're all IPOed. The proceeds are used to pay off first any expenses incurred by the government to ru

  • 'It's not a simple matter of removing certificates from a database, because they're not in any databases,

    I don't get this. Removing/replacing a CA cert from trust is easy for browsers/os vendors to do, technically (CA should be on the hook to re-certify certs if they are forced to remove their cert from circulation).

    With OSCP, at least *good* certificates *are* in a CA's database, and OSCP will fail for any signed certs that cannot update the OSCP server's hosted copy. Implementation wise, OSCP validation is done poorly, but that's not a flaw of the theoretical design.

    There is a whole lot of people calling t

    • convergence/perspectives use multiple servers around the internet called notaries, when you connect to a site you also connect to these notaries and ask what they see for the site (this is in perspectives mode, notaries can do other things in convergence), now if they don't match with what you got then either you or they are being MITM attacked and therefore the connection is dropped with an error (in convergence the user can control just how much of a match is needed, 1, majority, consensus). The idea is t

    • And if you kick a big CA like Verisign out, you'll basically break the internet since so many websites rely on certs signed by them.
      Sure, it's easy to remove/revoke a root cert. It's not easy to deal with the clusterfuck of having 80% of all HTTPS websites giving an error.

  • Alternative improvement idea (Score:5, Interesting)

    by vadim_t ( 324782 ) on Wednesday September 07, 2011 @05:14PM (#37333708) Homepage

    So I've seen quite a few people wanting a switch to self-signed certs (who IMO mostly don't understand what making that secure actually involves), and an idea to check certs from different network paths (which doesn't work if your only path is compromised, and how do you secure the communication to the service that does the check for you?).

    So here's an alternative idea: Require multiple CAs.

    Instead of doing it the "extended validation" way which is more money for not a whole lot more service from the same provider, it'd be much better to have multiple CA signatures on a single cert.

    Compromising multiple CAs in the same timeframe to create a cert would be considerably harder than creating one. More importantly, it'd make revoking large CAs much easier.

    Let's say that the new norm is to have a site's cert is signed by 5 different CAs, and that the minimum acceptable amount is 3 signatures.

    Then, if Verisign gets compromised there's no problem with pulling their cert: you're down to 4 valid signatures on your certificate, which is still fine. That should put considerably more pressure on CAs to perform better.

    Even Verisign wouldn't be able to trust that their security problems would be let go due to their popularity, as even the largest CAs would be completely expendable without the end users needing to care much. The site would just go with a different 5th CA to return back to the full strength.

    • Re: (Score:2)

      by ftobin ( 48814 ) *

      That's a fairly novel idea that would provide pretty good privacy.

    • Multiple path is done over SSL with certs to match against pinned in the browser. This is more a trust on first use, as is an exception for self signed. The only possible compromise time with this is that first connection to the notary (server for doing validation) or the self signed server.

    • Re: (Score:2)

      by flonker ( 526111 )

      He also claims to 0wn four more 'high-profile' CAs

      http://it.slashdot.org/story/11/09/06/1245214/Possible-Diginotar-Hacker-Comes-Forward [slashdot.org]

    • PGP style signing of certs. From the point of view of the customer, the SSL cert says it's been signed by 3 CA's I've never heard of, plus my IT department who seem to have some idea, plus my wizzkid brother in law who has OCD who I completely trust. My brother in law also trusts one of the CA's, but not the other 2. A score gets automagically generated, plus the details if I want them. If the CA screws up, my brother in law revokes his signature.

      • Re: (Score:2)

        by vadim_t ( 324782 )

        That would be possible under a system like that, but I think the current system of trusted by default CAs ought to remain. 99% of people simply aren't going to take time to understand how a PGP style works. I'd know, I explaned PGP to several people and it takes a quite long time to do properly.

        Besides, just what does your brother in law trusting a CA means? He thinks they're really professional? They are cheap and have nice customer service? But none of that has anything to do with their security and inter

    • So here's an alternative idea: Require multiple CAs.

      Instead of doing it the "extended validation" way which is more money for not a whole lot more service from the same provider, it'd be much better to have multiple CA signatures on a single cert.

      What you are proposing is roughly what the Perspectives [perspectives-project.org] project has implemented.

      • Re: (Score:2)

        by vadim_t ( 324782 )

        Not at all. My idea has absolutely nothing to do with what this project.

        My idea requires: Certificates to support multiple CA signatures, and for a browser to require multiple valid CA signatures on a cert. Other than that it fits perfectly well in the current scheme. You'd still get your cert signed by companies like Verisign and Thawte, and their certs would still come by default with the browser.

      • Re: (Score:2)

        by vadim_t ( 324782 )

        I found this [grepular.com], which mirrors my idea.

        I also looked at Perspectives.

        IMO, it's quite silly.

        First, the idea of it is to replace CAs with... a CA. It does exactly what any other CA does, except it implements a different policy. Instead of "we certify that bobsmith.com belongs to somebody named Bob Smith", or "the person who requested this cert proved they control http://bobsmith.com/ [bobsmith.com]", it's "we certify that this cert looks the same from everywhere".

        It is just as hackable as any other CA, though I guess it does h

        • It is just as hackable as any other CA, though I guess it does have the slight advantage of the attacker to modify their servers and keep the intrusion active, instead of breaking in, making a few certs, removing traces and disappearing.

          I disagree.

          The idea is that the client doesn't rely on just one notary, the client checks several of them, chosen at random from a large list. So the attacker has to compromise all of the notaries the client chooses to use, simultaneously, and without knowing which notaries the client might use. The attacker could block access to all of the notaries but the one he's compromised, but that's trivially defeated by configuring the client to require multiple successful validations, and to refuse to validate

  • Why doesn't each browser's company put up a certificate revocation server? Then, they can revoke individual certs, including those of the certificate authority, and control the length of the revocation, re-authorization, etc.

  • I point out that Comodo are compromised twice recently, and not revoked by any browser. As Moxie pointed out in his blackhat talk.

  • One thing is that I would love a costless distributed solution like the one Marlinspike suggests. I'd much rather trust a large group of peers than a company whose security practices may be questionable. Sure, the peers might be much less secure individually but as a group it's extremely hard to force something onto everybody thus causing manipulative results. If the network both rates the certificates and each other, it's next to impossible to introduce corruption on a level that matters.

    Now, given what we

  • What if you publish your own CA with the domain name in the DNS?

    You first make an CA and publish your public key as an TXT (or something similar) field to your root domain (name.tld) and using dnssec to make sure it's correct. You can now use that CA to make certs of all the names that you want within your own domain.

    If someone tries to make an CA of your name and try to intercept the dns traffic to change the public key, the dnssec would fail and in that case and the CA is invalid?

Slashdot Top Deals

"Tell the truth and run." -- Yugoslav proverb

Close