Forgot your password?
typodupeerror
Google Networking Security Technology

Google Researchers Propose Plan To Fix CA System 91

Posted by Soulskill
from the put-a-plus-one-button-on-it dept.
Trailrunner7 writes "The security industry has no shortage of hard problems to solve, but the one getting the most attention right now is finding a way to improve, or ideally, replace, the CA infrastructure. The latest in what has become a series of recent proposals to help shore up the certificate authority system comes from a pair of Google security researchers who have laid out a plan for providing auditable public logs of certificates as well as proofs for each certificate issued. The system proposed by Google's Adam Langley and Ben Laurie (PDF) comprises three separate ideas, but relies on the creation of a publicly viewable log of every public certificate that's issued by a CA. There could be any number of public logs of these certificates, but the logs will be structured so that they are append-only. The entries in the logs will be the end certificates in the issuance chain. In addition to the logs, the proposal includes the use of proofs that are sent with each certificate to the user's browser. Laurie and Langley haven't defined exactly what the proof would look like, but suggest that it could be an extra certificate or a TLS extension."
This discussion has been archived. No new comments can be posted.

Google Researchers Propose Plan To Fix CA System

Comments Filter:
  • Does SSH use a CA system?
    • by kassah (2392014) on Tuesday November 29, 2011 @07:29PM (#38208580)
      No it doesn't, with ssh you're generally not logging into a system and expecting to trust the security of a system based on it's name. SSH trust is based on have you been there before, and it having the same identity as before.
      • Which is exactly what browsers should do. But that doesn't solve the problem of CAs that can't keep their root keys secure.

        • by kassah (2392014)
          While that might work for bank logins or sites you visit regularly, but for normal e-commerce, that tactic is useless. You have to be able to quickly decide if you trust that this site is who they say they are (if you're smart, you look at the cert, where at least some validation took place), so that if there is a problem, you can at least identify who the culprit was. If I'm doing business with Amazon for the first time, I need to know that I'm talking with Amazon, not some proxy setup at my ISP to collect
          • by Anonymous Coward

            When you haven't shopped there before, you don't care if they are who they say they are. You care about whether or not you will get what you ordered, and what they will do with your credit card number.

            Being even 100% sure that joesautoparts.com is really owned by Joe doesn't help one bit, when you don't know that Joe has a huge dept, and will do anything (including emptying your credit card), to get enough money to start over in a different country.

            • by Rich0 (548339)

              I've never bought anything from Lord and Taylor. However, if I could be assured that I had an authenticated connection to a website they own I wouldn't have any concerns with buying something from them - because they have a real-world reputation that they have obtained over many years.

              I don't think the solution to the trust problem is to just pretend that nobody needs to trust anybody.

              All that said - reducing the need to trust people would certainly be good. Many of the problems with e-commerce stem from

          • by drakaan (688386)

            The main problem you noted (some proxy at your ISP set up to collect credit card info) isn't fixed by any CA setup that involves sending a cert from a site to a browser. If an ISP or network operator controls any part of the network between you and the site you are visiting, they can do absolutely anything with the data that passes through that portion of the network. They have very simple ways to grab copies of the certificate, modify responses from DNS servers, etc, etc...think "traffic shaping run amok

      • by errandum (2014454) on Tuesday November 29, 2011 @08:16PM (#38209112)

        How do you propose to verify someone's (or some site's) identity without having a trusted third party telling you that you should? What you say is kind of utopic, it might work to connect to somewhere you know, but it'll fail on a larger scale.

        And don't forget that it's not just you having to verify the website's identity, sometimes it is also the website asking to verify yours. Even if they used their own CA to hand you a certificate, they still needed a trust based system.

        Yes, I see your point, on a basic level ssh only relies on an asymmetric key exchange and sygnatures and not on CA's, but the problem is way bigger than that.

  • by Anonymous Coward

    Did anyone else read this as "Google plans to fix California"?

    No? Oh well.

    • I was halfway through the summary before I realized which CA they were talking about....
    • by LurkerXXX (667952)

      I thought they were talking about CA Technologies, a fortune 500 IT company.

      How hard is it to type out Certificate Authority? Why do slashot posters and editors suck so bad at titles and summaries?

  • Great news (Score:2, Offtopic)

    by Megahard (1053072)
    I live in California and it's a mess.
    • by eepok (545733)

      Ha! This was my first though.

      (Note to editors: Define your abbreviations or lose your audience.)

    • I live in California and it's a mess.

      What's it got to do with Calif? AFAIK, ca is the TLD for Canada...
      Oh wait, those wily Canucks must be angling for a Californian climate again.

    • by Khyber (864651)

      Google couldn't fix California. The problem is beyond the capabilities of the Ph.Ds at Google, because this is a problem involving the common man, and corruption. Even some of my tech and advances aren't going to help much without other changes.

      No doctor in the world could fix that.

  • by Anonymous Coward on Tuesday November 29, 2011 @07:32PM (#38208620)

    "Bob has a problem requiring secure communication. He decides to use certificates. Now Bob has two problems."

  • True story (Score:5, Funny)

    by aBaldrich (1692238) on Tuesday November 29, 2011 @07:35PM (#38208648)
    The new certificate system will be invitation-only, and then will be shut down.
    • by Anonymous Coward

      Step missing: spend 3 years in beta

  • Self signed certs. (Score:4, Interesting)

    by syousef (465911) on Tuesday November 29, 2011 @07:36PM (#38208660) Journal

    Let's all just give up and use self signed certs. Sure it's not secure but at least you don't have to pay for them then go through all the security theatre to pretend they are. You could change your web page to "Welcome. All our base are belong to YOU. We give up."

    • by Spad (470073) <slashdot@sp[ ]co.uk ['ad.' in gap]> on Tuesday November 29, 2011 @07:45PM (#38208778) Homepage

      Self-signed certs are just as secure as any other, they're just not much good for verifying the identity of the device you're connecting to unless they're your devices (or those of someone you know and trust); though given the laughable standards of proof required by most CAs before issuing a certificate for a given hostname (and yes, sometimes they *are* just hostnames that they're issuing for, for some stupid reason) it's probably not that big a problem even without the recent CA compromises.

      • by complete loony (663508) <Jeremy.Lakeman@noSpam.gmail.com> on Tuesday November 29, 2011 @08:20PM (#38209134)
        Solve that problem via DNSSEC. Publish your self signed key via DNS, and at least someone connecting knows that the server they are talking to currently owns the domain name and the connection is encrypted end-to-end, which is all that CA certs seem to have devolved to.
        • by John.P.Jones (601028) on Tuesday November 29, 2011 @10:00PM (#38209996)

          This is essentially what I proposed in my paper [acsac.org] in 2005, only it adds a level of indirection to reduce the amount and volatility of data being added to DNS.

        • by MSG (12810)

          DNSSEC is signed by CAs. If an attacker can compromise a CA, they can compromise DNSSEC.

          • Re: (Score:2, Insightful)

            by Anonymous Coward

            Are you sure about that? My understanding is that it is signed by the parent domain, all the way up to the root.

            As an example, if we take shop.example.dk, it is signed by the owner of example.dk, which is then signed by dk-hostmaster, and the .dk domain will be signed by the root key.

            Sure, all this will verify is that the FQDN you are connecting to is actually the FQDN you are trying to connect to, but as this is (or should be) part of the buying process, it's still way better than the current system where

  • Doesn't Fix Anything (Score:4, Interesting)

    by sexconker (1179573) on Tuesday November 29, 2011 @07:45PM (#38208774)

    The CA system is set up so that you can be reasonably sure that the host you're connected to is who they say they are.
    You "trust" that a certificate they present is legitimate because it is cryptographically signed by a CA.
    You trust the CA because you have a root list of CAs to trust, typically fed to you by MS.

    The problem with the CA system is the fact that the CAs themselves are untrustworthy.
    They don't do their due diligence in verifying hosts they issue certificates to, safeguarding their private keys, or revoking certificates when keys get stolen.
    The entire idea is insecure because users want shit to work transparently, and CAs want to do shit as cheaply as possible.

    You can have all the logs and auditing that you want, but when some soccer mom can't buy something on Amazon, your system has failed.
    And when some CA fucks up and nobody knows because no one is actually monitoring those logs, your system has failed.
    And if you DO have dedicated groups that monitor logs and do audits, it becomes the same fucking game of knowing which monitoring group to trust, how far to trust them, etc. 99.9999% of users will just be confused, and will think their next computer crash has something to do with the internet hacks Wolf Blitzer told them about.

    The only way to trust a host is to verify their identity yourself. And if you're going to go and fucking verify the trustworthiness of CAs via analyzing their logs yourself, you may as well just verify the trustworthiness of individual sites yourself. Call up Amazon and ask them about their certificate. Maybe they should print it on the back of all their packing slips.

    • Basically, it's a societal issue that starts and ends in meat space. Trust, as a concept, is the social lubricant that allow human progress an interaction to carry on unimpeded. Without a culture of trust, progress slows down or stagnates all together. So really, technology doesn't solve this problem. Its trustworthiness is merely a reflection of society as a whole.

    • Call up Amazon and ask them about their certificate. Maybe they should print it on the back of all their packing slips.

      It may sound stupid, but with the current proliferation of QR codes, that idea isn't quite as far fetched as you may think...

      • I don't think the idea is far fetched (in terms of feasibility). I think it's unlikely because the bottom line is no one gives a shit about security - they give a shit about users being able to spend money.

        Can a current QR code can hold enough data for a signed certificate?

  • Not a fix (Score:5, Interesting)

    by Todd Knarr (15451) on Tuesday November 29, 2011 @08:03PM (#38208962) Homepage

    The proposed solution makes it easier to identify invalid certificates after a compromise is known. It doesn't do anything to stop the compromise, because the compromised certificates were issued correctly by the CA just like every valid certificate.

    The problem is that the CAs aren't completely trustworthy and aren't completely impervious to attack, and never will be. Any solution needs to permit a compromised CA's root certificates to be revoked without instantly invalidating huge swathes of issued certificates that weren't part of the compromise. I don't see any way of doing that that doesn't involve changing the basic approach from one of "a single CA issues a specific certificate" to "one or more CAs certify the authenticity and validity of a certificate'. In short, CAs cease being the sole issuers of documents and become the equivalent of notaries public certifying that the person who created the certificate is really who the certificate says they are.

  • Where's my cheap energy? You promised to fix that too!
  • by Megahard (1053072) on Tuesday November 29, 2011 @08:18PM (#38209124)
    So eventually it will be certificates all the way down.
  • I read the summary multiple times. What exactly is Google trying to fix with California?
  • Another extension of a corrupt system to corrupt further.
  • This sounds an awful lot like a bitcoin-style blockchain. There is of course no double-spending problem to solve but mining can go to pay for the cert-certifying nodes.
  • Or we could just use a solution that was already thought out pretty well, doesn't require massive infrastructure change, actually addresses the problem (i.e. as end users we have to trust the entire certificate chain, and ultimately the CA).

    http://www.convergence.io/ [convergence.io]

    And go listen to Moxi's defcon talk about this.

    • by whois (27479)

      You're right DNSSEC is not the answer, but Convergence has problems.

      From a previous post I made:

      "The problem I foresee is that users won't change notaries based on trust. Most users click yes to anything, don't know what's going on 99% of the time and have no clue/don't want to know how crypto works on the internet."

      There is also the privacy issue of sending a certificate request to number of notaries, meaning someone out there knows what sites you're browsing and when.

      Or the bandwidth consideration of ask

  • I think I would prefer Moxie Marlinspike's Convergence [wikipedia.org]. That way you can at least trust the CA:s a little less. The talk from BlackHat is quite enlightening.

  • Proposing BitCA then?
  • Wikified certificates, anyone?

The Tao doesn't take sides; it gives birth to both wins and losses. The Guru doesn't take sides; she welcomes both hackers and lusers.

Working...