Slashdot Mirror

← Back to Stories (view on slashdot.org)

Google Researchers Propose Plan To Fix CA System

Posted by Soulskill on 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."

91 comments

  1. Not Impressed by masternerdguy · · Score: -1, Troll

    Too bad they censor the internet. Why doesn't google just get into hosting as well, then they can rebuild the entire internet themselves (hosting, advertising, and certificates). We need a UN body to take over the internet so that one country or one corporation can't have a strong influence on it.

    --
    To offset political mods, replace Flamebait with Insightful.
    1. Re:Not Impressed by mugetsu37 · · Score: 1

      There are enough issues that Google has to deal with that are monopoly-related. By getting into hosting, Google would essentially be committing business-suicide.

    2. Re:Not Impressed by quasius · · Score: 2, Insightful

      What are you talking about re: Google censoring the Internet? Also, what convinces you that the UN would do a better job? What large nation isn't putting corp interests first that would influence a UN body to behave differently?

    3. Re:Not Impressed by masternerdguy · · Score: 0

      Among other things, requiring you to log in to view youtube videos someone has flagged as "offensive". They also remove search results that the US government doesn't like for whatever reason, being an American company. The UN can do better because it theoretically represents the interests of more than just the US, and since the internet is international they should be the authority on it.

      --
      To offset political mods, replace Flamebait with Insightful.
    4. Re:Not Impressed by CannonballHead · · Score: 1

      Because the UN handles so many highly controversial* issues so well as it is.

      * Humanitarian aid is not really a controversial issue. Nuclear power is.

    5. Re:Not Impressed by korgitser · · Score: 3

      The UN is not some world government for some happy hippie peace dream. It is a machine to legitimize the ends and means of select superpowers. You certainly do not want any of them to have power over the internet.

      --
      FCKGW 09F9 42
    6. Re:Not Impressed by Anonymous Coward · · Score: 0

      Movies flagged 'offensive' have to be blocked unless you are logged in to verify age... and you apparently never surf youtube for videos of US dissent.

    7. Re:Not Impressed by masternerdguy · · Score: 3, Funny

      Age verification is censorship.

      --
      To offset political mods, replace Flamebait with Insightful.
    8. Re:Not Impressed by AliasMarlowe · · Score: 1

      The UN can do better because it theoretically represents the interests of more than just the US, and since the internet is international they should be the authority on it.

      In principle, your argument has some merit. In practice, it is probably enormously flawed. The general concern is that under UN regulation global internet censorship would encompass the union of all local censorship wishes (biases of all religious viewpoints, every tinpot dictator or wannabe, DRM morons, etc.), rather than just their intersection (probably just kiddie porn, snuff videos, and suchlike).

      --
      Those who can make you believe absurdities can make you commit atrocities. - Voltaire
    9. Re:Not Impressed by errandum · · Score: 1

      No, I'm quite sure it is a requirement in some countries (I'd even guess that every country has a law requirement for certain themes).

      I guess you'd prefer to have Google censor the whole website because they were blocked from running it instead of trying to verify your age..

    10. Re:Not Impressed by PaladinAlpha · · Score: 0

      This is probably the most nonsensical thing I've heard all year.

      Okay. One, you obviously don't have kids. Age of majority isn't arbitrary, and it's worth at least putting up a few bumps between children and some of the more out-there stuff. Two, if you can access the material, it's not censorship -- and if you can't access content protected by age verification, then you are not part of the voting body, and are therefore a non-entity vis-a-vis the government, and therefore cannot be a target of censorship. Three, read one and two again.

    11. Re:Not Impressed by shentino · · Score: 2

      Age of majority IS arbitrary.

      It's whatever the law of the nation that is sovereign over the citizen in question SAYS it is.

      The government telling you what you can or cannot do is pretty much the definition of what a law is.

    12. Re:Not Impressed by tepples · · Score: 1

      If it's not arbitrary, then why are some things 16 and others 21, and why does it vary by country?

    13. Re:Not Impressed by nedlohs · · Score: 1

      Yes, much better they just blocked their entire site in countries which have laws requiring them to make some sort of token effort at it.

      Because that wouldn't be censorship.

    14. Re:Not Impressed by PaladinAlpha · · Score: 1

      Perhaps we disagree on what arbitrary means. Are laws against murder arbitrary? If you think so, then we simply will not agree on this issue.

    15. Re:Not Impressed by PaladinAlpha · · Score: 0

      If it is arbitrary, why doesn't it vary across country in a completely random distribution from 1 to (say) 70?

    16. Re:Not Impressed by Firetoad · · Score: -1

      God dammit you're an idiot. A mind-blowingly hude idiot. Wow. I'm seriously impressed by your idiocy.

    17. Re:Not Impressed by heinousjay · · Score: 1

      I find your faith in authority disturbing

      --
      Slashdot - where whining about luck is the new way to make the world you want.
    18. Re:Not Impressed by Anne+Thwacks · · Score: 1
      Speaking as someone who is not a US citizen, The UN is infinitely preferable to the US.

      My proposed solution is "The US has jurisdiction in the US, the UN covers the rest of the world!"

      We the people don't like your US government or its policies, and even if we did, they are not OURS.

      Or in the words of the 20th century - "we dont like your imperialist behaviour very much",

      --
      Sent from my ASR33 using ASCII
    19. Re:Not Impressed by Anonymous Coward · · Score: 0

      Censorship is a requirement in some countries. That does not make it not censorship.

    20. Re:Not Impressed by mr100percent · · Score: 1

      The UN is not set up that way to be the pawn of superpowers. Granted, countries like the US can throw a lot of their weight around (e.g. see how they lobbied other countries to vote No or Abstain on recognizing a Palestinian state), but the majority of the members are democracies.

    21. Re:Not Impressed by Anonymous Coward · · Score: 0

      He is a paladin, after all.

  2. Something To Think About by Zamphatta · · Score: 1

    Does SSH use a CA system?

    1. Re:Something To Think About by kassah · · Score: 4, Informative

      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.

    2. Re:Something To Think About by Anonymous Coward · · Score: 0

      Why do you think it asks if you trust the machine first?

      SSHFP DNS records provide a fair workaround to this issue, but they have never caught on, and DNS cannot be relied on anymore anyway.

    3. Re:Something To Think About by Score+Whore · · Score: 2

      Which is exactly what browsers should do. But that doesn't solve the problem of CAs that can't keep their root keys secure.

    4. Re:Something To Think About by XanC · · Score: 4, Informative

      But that's exactly wrong. With DNSSEC (well, hopefully) becoming more popular, it WILL actually be possible to rely on DNS to store things like key fingerprints.

    5. Re:Something To Think About by kassah · · Score: 1

      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 credit card info. I know based on the name their reputable, but I may only order there once a year, at which time there should be a new certificate each time I go.

    6. Re:Something To Think About by John.P.Jones · · Score: 2

      In 2005 I published a paper that proposes essentially this, along with providing an entry for DNS to delegate key query for a domain to a secondary key server (so that only a small number of key fingerprints need to be added to DNS for a domain) and key certificates are signed with these keys and available along with key metadata in an XML format.

    7. Re:Something To Think About by errandum · · Score: 3, Insightful

      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.

    8. Re:Something To Think About by errandum · · Score: 1

      In theory this is all very cool, but how do you propose to make it backward compatible and / or to convince everyone that something that works reasonably well should be changed / invested in?

      The methods for a secure DNS (and POP and IMAP and SMTP and ) have been here for years and are actually taught to most CS majors, but having the tech is rarely the only concern (unfortunately)

    9. Re:Something To Think About by errandum · · Score: 1

      had no idea ">" and "" could be used as html tags, and so some of my text got eaten.

      where it reads ... and SMTP and ) should be ... and (insert most original internet protocols)

    10. Re:Something To Think About by shentino · · Score: 3, Interesting

      DNSSEC is unpopular with governments because it breaks censorship.

    11. Re:Something To Think About by Anonymous Coward · · Score: 0

      I dunno about you but I definitely don't trust DNS registrars.

    12. Re:Something To Think About by John.P.Jones · · Score: 2

      Current protocols that agree on a public key do so via certificate chains signed by a CA, which we don't necessarily trust (or wish to fund) and we would like to have the option to remove them from the chain, but then we need somewhere else to root trust. DNS is the natural place to do that in today's internet (who has the authority to assign me a gmail.com address, why the owners of that domain do of course, if they wanted to give that name to someone else only they could, once you own a registered domain you have rights to subdomain it to whomever you please and they have to trust you not to revoke it).

      The proposal is to have this certificate chain rooted at a per domain CA (or the domain can choose to use an existing CA) so that both the fingerprint of the CA's signing key and the authority of the CA to vouch for this domain are both leveraged from DNS not some arbitrary out of band trusted party. The protocol would agree on keys just as it does today but when the certificate chain is being validated it would then verify the CA with the proper domain (for e-mail, ftp, http, ssh etc the owning domain is well understood from context) before accepting the key. No real change is needed to the underlying protocols (although the implementations need to be changed slightly just as they would for accepting a CA's new signing key), essentially every key validation would end in a couple additional DNSSEC resolution queries.

      Of course this is a chicken-egg problem in that it then ties back into DNSSEC and root level trust in DNSSEC needs to be solved (through CAs for now) but it decouples the problem and leverages the architecture of DNSSEC (we really do need it anyways) to provide arbitrary certificate trust without putting undo burden on DNS. If we are going to have to have DNSSEC to fix DNS we may as well use it for more than just name to IP resoultion. There is no reason to solve the trust problem more than once since and as long as we use DNS based hierarchies to specify machines or end users (e-mail accounts) we have to trust DNS. The fact that today pre-DNSSEC we blindly trust unsigned DNS replies is the only reason the parallel certificate hierarchy exists at all.

    13. Re:Something To Think About by bill_mcgonigle · · Score: 1

      to a secondary key server (so that only a small number of key fingerprints need to be added to DNS for a domain)

      Why not stay within DNS? Delegate queries to a subdomain if it gets huge?

      --
      My God, it's Full of Source!
      OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
    14. Re:Something To Think About by Anonymous Coward · · Score: 1

      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.

    15. Re:Something To Think About by Rich0 · · Score: 1

      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 some weaknesses in our banking/payment system:

      1. The only practical and universal way to submit a payment to somebody online relies on giving them a 16-20 digit number that they can then use to impersonate you.
      2. The only way to prove your own identity (so as to obtain credit) is to give somebody information that they can then use to impersonate you.
      3. The credit card system is the closest we have come to some kind of universal escrow system, and it isn't very good. It provides little assurance to either party that they will prevail if they are in the right.

      I can think of some fixes, though some would be controversial:

      1. Require credit card companies to use hardware tokens to authenticate transactions. The necessary keys to authenticate a transaction should ONLY exist on the token, and should never leave the token. The token should not trust any digital input it receives from the outside world, and should assume any output will be tampered with. The only trusted interface should be a small display and keypad used to verify the card owner is present and approves the transaction.

      2. Have the government issue ID cards to everybody. They should include hardware tokens with keys that never leave them to make it virtually impossible to copy them. I haven't thought as much about the implementation of these, but they should obviously have a trust chain and a revocation list. They should probably provide some ability to apply digital signatures to arbitrary statements - perhaps with an embedded display and a PIN pad. Again, they should not trust any external hardware, and should assume that any output will be tampered with.

      3. Have a good legal framework around payments/identity in general. If the government incorrectly issues ID then the government will both insure people against innocent losses as a result of trusting those IDs, and nail to the wall the people who misused them. Banks should be responsible for verifying identities of anybody they do business with, and should be responsible for reimbursing consumers for any loss if a merchant defrauds them on a payment they process (they can then go after the business, and would have incentive to vet merchants as a result).

      If the whole electronic payment/identity thing worked properly, then I wouldn't care if Joe's Auto Parts is legit or not, because I don't stand to lose anything if they aren't. No doubt the bank would make them jump through hoops, and if they felt they didn't have enough property to seize they might require bonds. Since Joe likely only has a relationship with one bank, but potentially millions of customers, it makes sense to put the burden of vetting him on the bank.

    16. Re:Something To Think About by Daniel+Boisvert · · Score: 1

      Of course this is a chicken-egg problem in that it then ties back into DNSSEC and root level trust in DNSSEC needs to be solved (through CAs for now) but it decouples the problem and leverages the architecture of DNSSEC (we really do need it anyways) to provide arbitrary certificate trust without putting undo burden on DNS. If we are going to have to have DNSSEC to fix DNS we may as well use it for more than just name to IP resoultion. There is no reason to solve the trust problem more than once since and as long as we use DNS based hierarchies to specify machines or end users (e-mail accounts) we have to trust DNS. The fact that today pre-DNSSEC we blindly trust unsigned DNS replies is the only reason the parallel certificate hierarchy exists at all.

      In the current arrangement, the parallel CA hierarchy allows you to provide a (theoretically) verifiable connection despite your registrar or DNS provider being perhaps less reputable than you'd like. For an attacker to silently redirect your SSL traffic, he has to compromise at least two external entities--your CA & DNS host/registrar or your CA and somebody in a position to MITM your traffic (obviously a local compromise gets him everything, but this is within your direct control). While I'm no fan of the CA model, the stuff pulled by companies in the DNS market (registrars and hosts both) make the CA's look positively responsible, and handing them all the keys necessary to silently redirect traffic makes me uneasy.

      It seems that by suggesting these functions be consolidated into DNS, you're effectively saying that by consolidating two untrustworthy parties into one untrustworthy party, you'll be more secure. I'm pretty sure I don't agree with that, but I'm willing to listen. How do you address such criticism?

    17. Re:Something To Think About by Anonymous Coward · · Score: 1

      Possible, yes. It's also a terrible idea: http://blog.thoughtcrime.org/?sort=&search=dnssec

    18. Re:Something To Think About by drakaan · · Score: 1

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

      Because of the way that SSL/TLS is implemented, the issue of identity is definitely an issue of trust, but if you can't trust every network between you and the site you hope to access, then it's all meaningless. For that matter, if you *could* trust every network between you and the website, certificates at the site you're visiting would still be meaningless, since you'd be sure that you had arrived at the right location. At that point, having your own certificate and using *that* to secure the communication would make more sense.

      The whole setup is so secondary to the functional workings of the internet that there's no real way to ever trust anything, when you get down to it. Who here can say there's no way for some rogue ISP with a peering agreement to intercept, modify, mangle, and misuse whatever packets it wants?

      --
      "Murphy was an optimist" - O'Toole's commentary on Murphy's Law
    19. Re:Something To Think About by mdmkolbe · · Score: 1

      How does DNSSEC interact with the recent SOPA/PIPA/ICE-takedowns? Some have suggested alternatives to DNS to avoid government interference. Is DNSSEC subject to the same sorts of interference?

      (It strikes me as comical that the pro-DNSSEC and the anti-SOPA/PIPA/ICE crowds might be working at cross purposes.)

    20. Re:Something To Think About by Lennie · · Score: 1

      That might be, but that does not mean we all think that the current setup for DNS should be the only-CA for everything (because that is what DNSSEC/DANE is, a trust model with only one CA, the DNS-root).

      The organisations which handles what goes into the root are ICANN, ARIN and Verisign. All US organisations, all have to abide by the US rules/laws/pressures.

      Only the root server administrators can stop the root being published, but as the root is signed and it will expire. They are pretty much forced to only block it until it expires and disable the DNSSEC system all together.

      An example of a few days ago:

      "US Gov't Seizes 130+ More Domains In Crackdown"

      http://yro.slashdot.org/story/11/11/26/1453227/us-govt-seizes-130-more-domains-in-crackdown

      I'm not saying it is a bad idea, I'm just trying to make clear that it isn't perfect. Not perfect it all.

      --
      New things are always on the horizon
  3. Not a bad idea by Anonymous Coward · · Score: 2, Funny

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

    No? Oh well.

    1. Re:Not a bad idea by TheNastyInThePasty · · Score: 1

      I was halfway through the summary before I realized which CA they were talking about....

      --
      The best thing about UDP jokes is I don't care if you get them or not
    2. Re:Not a bad idea by LurkerXXX · · Score: 1

      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?

  4. Great news by Megahard · · Score: 1, Offtopic

    I live in California and it's a mess.

    --
    I eat only the real part of complex carbohydrates.
    1. Re:Great news by eepok · · Score: 1

      Ha! This was my first though.

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

    2. Re:Great news by AliasMarlowe · · Score: 1

      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.

      --
      Those who can make you believe absurdities can make you commit atrocities. - Voltaire
    3. Re:Great news by Khyber · · Score: 2

      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.

      --
      Still waiting on Serviscope_minor to wake up to fucking reality and realize that Jessica Price isn't going to fuck him.
  5. It's like that old saying about regexes... by Anonymous Coward · · Score: 5, Funny

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

    1. Re:It's like that old saying about regexes... by Anonymous Coward · · Score: 0

      Lol, this just made my day. Thank you.

    2. Re:It's like that old saying about regexes... by Anonymous Coward · · Score: 0

      Certificates aren't the problem, certificate authorities are the problem.

    3. Re:It's like that old saying about regexes... by Nursie · · Score: 1

      +1 (if I had mod points)
      TLS is pretty secure and improving by revisions, Certificates themselves are pretty damn clever.

      OTOH public trust infrastructure is a very hard problem to solve and we clearly don't have it right at the moment.

  6. Not even Google... by Anonymous Coward · · Score: -1

    California is far too broken for even the mighty Google to be able to fix it.

  7. True story by aBaldrich · · Score: 5, Funny

    The new certificate system will be invitation-only, and then will be shut down.

    --
    In soviet russia the government regulates the companies.
    1. Re:True story by Anonymous Coward · · Score: 1

      Step missing: spend 3 years in beta

  8. Self signed certs. by syousef · · Score: 3, Interesting

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

    --
    These posts express my own personal views, not those of my employer
    1. Re:Self signed certs. by Spad · · Score: 5, Informative

      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.

    2. Re:Self signed certs. by complete+loony · · Score: 4, Insightful

      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.

      --
      09F91102 no, 455FE104 nope, F190A1E8 uh-uh, 7A5F8A09 that's not it, C87294CE no. Ah! 452F6E403CDF10714E41DFAA257D313F.
    3. Re:Self signed certs. by Anonymous Coward · · Score: 0

      Let's skip certs altogether and use PAKE.

    4. Re:Self signed certs. by John.P.Jones · · Score: 3, Insightful

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

    5. Re:Self signed certs. by MSG · · Score: 2

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

    6. Re:Self signed certs. by Anonymous Coward · · Score: 2, Insightful

      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 a CA will give a key to anyone.

      Example: When a CA gave a fraudster a certificate to microsoft.com, Microsoft didn't have anything to do with it. In the system I'm talking about (which is my understanding of how DNSSEC works), the only one able to sign keys for a host under the microsoft.com domain would be Microsoft.

  9. Doesn't Fix Anything by sexconker · · Score: 4, Interesting

    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.

    1. Re:Doesn't Fix Anything by DigiShaman · · Score: 1

      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.

      --
      Life is not for the lazy.
    2. Re:Doesn't Fix Anything by DarwinSurvivor · · Score: 1

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

    3. Re:Doesn't Fix Anything by sexconker · · Score: 1

      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?

    4. Re:Doesn't Fix Anything by Anonymous Coward · · Score: 0

      Does it need to? A fingerprint (preferably in https://en.wikipedia.org/wiki/Biometric_word_list ) could encode the fingerprint fairly easily - the PGP fingerprint they list is 168 characters with spaces and a Type 7 (http://blog.qr4.nl/page/QR-Code-Size.aspx) QR code could easily hold it.

  10. Not a fix by Todd+Knarr · · Score: 4, Interesting

    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.

  11. Screw CA schme-A ... by davegaramond · · Score: 1

    Where's my cheap energy? You promised to fix that too!

  12. An extra certificate sent to the browser by Megahard · · Score: 3, Funny

    So eventually it will be certificates all the way down.

    --
    I eat only the real part of complex carbohydrates.
    1. Re:An extra certificate sent to the browser by Anonymous Coward · · Score: 0

      Came here for the turtles. Wasn't disappointed.

  13. Fix California? by ittybad · · Score: 0

    I figure Canada does not need much fixing -- not that I know of these things. I'm glad to see that Google is working on fixing California. Oh, wait. What?

    --
    No single raindrop believes it is to blame for the flood.
  14. What are they trying to fix in California? by jmcbain · · Score: 1, Interesting

    I read the summary multiple times. What exactly is Google trying to fix with California?

    1. Re:What are they trying to fix in California? by Anonymous Coward · · Score: 0

      All of California's infrastructure. I believe that Google is looking to fix all the road, bridges, water/sewer and such. I know, kind of a strange thing for Google to be getting into, but that is CA for you. A bunch of fruits and nuts.

  15. And so comes a new market of clean history certs by ihateslashfags · · Score: 1

    Another extension of a corrupt system to corrupt further.

  16. Maybe no Doctor in this world... by SkimTony · · Score: 3, Funny

    But that would admittedly be a pretty boring episode. And not the sort of thing he usually worries about.

  17. Enter a blockchain by Statecraftsman · · Score: 1

    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.

    1. Re:Enter a blockchain by Anonymous Coward · · Score: 0

      Exactly, bitcoin has solved this problem already.

  18. Free Lunch by Anonymous Coward · · Score: 0

    People are stupid and trust everything anyway, just put a picture of a padlock on it.

  19. tit for tat by Anonymous Coward · · Score: 0

    companies operating ecommerce websites think nothing of asking for our credit card details... perhaps we should only trust ecommerce websites that would be willing to provide bank details to us customers. if you are concerned, you can always get on the dog n bone and ask the bank if the details are legit. i don't like banks, but like most people i trust them more than i trust any ecommerce website.
     
    ... patent pending

  20. You ALMOST got it right. by Anonymous Coward · · Score: 0

    The real problem with the CA system is that if even just ONE CA is untrustworthy the entire system is broken.

    The root of the problem is that Any CA can create a certificate for ANY domain at ANY time, whether the domain owner wanted them to or not.

    So, CNNIC (a Chineese root authority) can simply create certs for ANY site, even public facing US military sites, or "$YourBank.com".
    Thus, the CA system is FUNDAMENTALLY flawed at its core, an no amount of dilligence on the 99.99% of all CA's part will rectify the issue of just a SINGLE CA bringing down the whole system's trust. I'm not picking on China. Google has a CA, they can create certs for anyone too...

    DigiNotar was a CA, they DID create certs for EVERYONE. Ask yourself if you think ANY system that lets ANY CA even have the POSSIBILITY of creating a *.* cert is going to be a good system... Who's bright idea WAS that?!

    TL;DR: It has never ever worked as intended, and will never do so.

  21. DNSSEC is not the answer by cmat · · Score: 1

    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/

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

    --
    -- Humans, because the hardware IS the software.
    1. Re:DNSSEC is not the answer by whois · · Score: 1

      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 asking number of people for trust information about a certificate.

      Proxying the information means you're back to trusting one person (who you might as well call your CA, since that's the business a CA will get into if we switch).. and it still doesn't fix the privacy concerns (unless you use multiple proxies and then it's bandwidth, unless you use only one at a time in rotation and then there's the issue of who to trust)

  22. Convergence by iamweasel · · Score: 1

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

  23. Web of Trust? by Anonymous Coward · · Score: 0

    What's wrong with Web of Trust? https://en.wikipedia.org/wiki/Web_of_trust

  24. So... by leptechie · · Score: 1

    Proposing BitCA then?

  25. WikiCert? by doubleyou · · Score: 1

    Wikified certificates, anyone?

  26. like the CA system, DNSSEC has its own authorities by Onymous+Coward · · Score: 1

    Building on top of DNSSEC leaves you maximally as secure as DNSSEC itself. The IETF document you reference in your paper, "Threat Analysis of the Domain Name System", lists among several weaknesses:

    Like DNS itself, DNSSEC's trust model is almost totally hierarchical. While DNSSEC does allow resolvers to have special additional knowledge of public keys beyond those for the root, in the general case the root key is the one that matters. Thus any compromise in any of the zones between the root and a particular target name can damage DNSSEC's ability to protect the integrity of data owned by that target name. This is not a change, since insecure DNS has the same model.

    In any SSL+DNSSEC paradigm you are trusting:

    • the root (ICANN)
    • the TLDs (e.g. Verisign)
    • the registratrs

    Which is very concerning, is it not?

    What about ICANN's not-legally-authorized seizure of domains? What about Verisign's domain slamming or DNS hijacking (breaking NXDOMAIN) or their own domain seizures? What about how registrars are often as sketchy as CAs and not as vetted?

    Please can we move away from DNSSEC or any other overly centralized and rigid (i.e. choiceless) system as a foundation for our security?

  27. more on choice... by Onymous+Coward · · Score: 1

    Have any of you edited your CA list to remove bad CAs?

    With DNSSEC, you won't be able to remove any authorities.

    This is not an improvement.