The problem with the root of trust problem is that you have to trust someone. Who is your preference? The government? The registries? ICANN? The hardware vendor? Those are all suspect too, and most have been historically compromised.
The only thing I can see that helps is "community" auditing -- things like Chrome's pinning and ... the action that discovered these new certs. So, as much as it sucks, we're sort of doing the right thing already.
https://tools.ietf.org/html/rfc6962 http://www.certificate-transparency.org/
(disclaimer: I work on this project)
No, silly: the domain owner! Something that's already possible with DANE: the domain owner gets to decide, as it should be, by publishing information about valid certification into the DNS.
Of ALL options this one is the least crappy IMO.
Also, DNSSEC still has some severe issues in practice. I'd be glad if we could get DANE widely deployed for mail servers.
Edit: Oh, and if you're not using a validating resolver yourself you're also trusting that you're ISP is using one and not manipulating the responses.
I really don't understand why people keep repeating that complaint. Of course, if you don't check the keys you don't get any security.
How is that a problem of the algorithm? And how is that a problem on practice? If you want some real amount of security you check the keys, being them SSL certificates, DNSSEC signatures, or whatever else encryption system people put on place.
That's why DANE for mailserver is such an attractive target. They're usually run by people who know what they're doing and it helps bring a lot of infrastructure into place.
The fact that current software is hard of configure is just a symptom that it's badly designed. The only inherently hard thing in DNSSEC is distributing your domain data (not really harder than setting our server for TLS), and normal people do not do that.
I think the trust model is broken for the same reason it can be said three can keep a secret, if two of them are dead.
How can humans create a software or hardware system that absolves us of the issue of trust, when people are, and have always, been up to no good.
The courts are full of people who claim other people have acted outside of good judgement.
I don't think it's possible to have trust without its opposite.
I'd like to be proven wrong.
Since we already are at the point where the security of the system hinges on the registrar, why not at least limit the damage potential by only accepting certificates issued by the registrar in question? Instead of letting any CA under the sun ALSO issue these?
PS: If certificate issuance was a required and expected task for all registrars, it could even lead to $0 certificates, which would surely boost HTTPS usage. It would even provide an incentive to pick a thorough registrar if you are concerned about security and validation, since no other entity could issue illegitimate parallel certs behind your back. Brings some meaning back to being a high quality authority (even charging more for more trust) instead of the race-to-the-bottom we have today. Sloppy registrar-CAs would lose business because their trustworthyness actually means something for once. (You wouldn't register your serious domain with a registrar known to have poor validation checks in place for issuing certificates, for example)
You seem to have gotten things backwards. If the DNS is hijacked, SSL is the only thing protecting a visitor from being lured into the hijacked site.
Connecting these two things into one makes SSL effectively worthless.
They way it is now, hijacking DNS (between the domain NS servers and any CA) would allow an adversary to request and obtain an illegitimate certificate by way of domain validation. If the registrar is the only valid issuer of certificates, this loophole is closed since there is nothing for the CA to verify - the registrar already knows who the customer is and can offer certificate signing without an insecure DNS based domain validation.
For end-users with a hijacked DNS, the registrar-issued SSL certificate would still protect the transmission, because the DNS-spoofing adversary would not be able to present a valid certificate signed by the registrar. In fact, in today's CA environment, if the DNS hijacker is playing ball with a rogue CA, they could also spoof the SSL. With my suggestion, they couldn't, unless the rogue CA is actually the registrar, because the browser would see that the SSL certificate was not signed by the appropriate registrar.
You could create a DNS-style CA setup like this:
* Browsers would ship with ONE root CA, the public key of the "." root zone operator
* Each TLD ("com", "org" etc) has a CA signed by the root zone operator, valid only for signing TLD registrar CAs. The root zone CA could publish a signed list of TLD certificates daily/weekly/monthly (they shouldn't change too often and the number of entries would be relatively low). Anyone could compare notes and see if these change. There aren't any hidden intermediary CAs. Browsers could sync this list daily/weekly/monthly, the deltas should be minimal. ISPs could even provide mirror services, because the whole list is signed by the root zone operator anyways.
* Each registrar under a TLD has a CA certificate signed by the TLD operator, valid for only signing secondary domains under the given TLD. (i.e. customer domains). Just like the RootZone->TLD signed list of CAs, the TLD CA operator could publish a signed list of registrar certificates daily/weekly/monthly (again, they shouldn't change too often and the number of entries would be relatively low). Again, anyone can compare notes and see if things change. No hidden intermediary registrars. Browsers could yet again sync this daily/weekly/monthly and ISPs can mirror the list since it's signed.
* Registrants of customer domain ("example.com", "example.org" etc) can request a domain-specific CA at their registrar, and only at their registrar. This domain-specific CA is valid only for signing leaf domains, i.e. "www.example.com", "mail.example.com". With the domain-specific CA in hand, the customer can create their own leaf domain certificates "at home". The registrar should offer non-EV domain-CA certificates for free (there is no work to be done to validate domain ownership as the customer already has an account there), or charge a fee for EV certificates.
* There needs to be a way to determine who is the valid registrar for a given domain. This could be for example a TLS-based machine-readable WHOIS service address operated by each TLD. The TLS-based WHOIS service would negotiate TLS with the same TLD-CA-certificate as specified in the root list. Thus, a browser can connect to the TLD's WHOIS service and validate that a given domain is under a given registrar, and that the leaf SSL certificate is signed by the domain CA certificate, which is signed by the registrar CA certificate, which is in the signed-by-the-TLD list of registrars, which is in the signed-by-the-root-zone list of TLDs. This stuff could also be cached at the ISP level because everything is chain signed.
Maybe this is how DNSSEC works (I haven't looked into the details), but I think this would be a pretty neat way to limit the damage done by rogue CAs.
Not exactly, but it's very similar. DNSSEC has no concept of registrars, and each zone is entirely signed by the same entity.
You'd trust that single entity to inform the registrar anyway, so descentralizing it gains you nothing.
I would have to think about it but I'm sure there is SOME way to verify someone (either in person or digitally). This process would only have to happen once to verify the CA cert for their domain. After that - if their CA cert is compromised it's not a big deal because it only affects one domain.
Oh - and any hoster that allows it's employees to reset virtual machine passwords or make account modifications via email/support ticket should NOT be allowed to participate in this scheme.
And if you require some level of authentication you are back to the same problem.
If you are instead saying that you should avoid having a URL in the certificate itself, validate it as normal and then use the DNS record to match the certificate to the URL I guess that could work. However you still have the above problem where anyone who has a valid certificate at all can impersonate any website by injecting a DNS record.
Of course I've since learned how awfully inertial the banking industry is and that the security of financial transactions is a lot of hand-waving and wishful thinking. On top of that, there's outright corruption of banks profiting from theft and always cooperate with governments.
So the answer is, you shouldn't have to trust anyone. The security infrastructure must be built assuming hostilities are everywhere. Any trust that is given should be limited to just what is necessary to accomplish the task at hand.
A PKI system like we have now is one of them, but we need a system where that is not the only available trust. Yes, it will be necessary to educate people about this topic (and never discussing it with the user will only keep them ignorant). Right now we have a system where users are forced to trust various CA, and if someone decides they want to trust something else, that is difficult or impossible.
The problem of WHO to trust for a particular website (that is, every website) is a separate problem which can be solved over time. My point is that we don't even have the tools to let people even being to solve that problem.
Yes. They should pay a service to keep track of who they should trust. They wouldn't be opened up to any more risk by this than as with the status quo, MS + Apple + Google would end up giving it away for "free" for those don't have a problem with that or don't know better, and the option to get more technical about issues of trust would always be available to them.
The industry does not encourage users to think and learn. The industry wants its software to do the thinking for them. It doesn't want users to think about trust at all. I think that is the scariest part of where things are heading.
It isn't about being passive; it's about having lives and jobs and other things to do with their time. A heart surgeon may be a genius but he doesn't have time to keep up with the latest research and teach himself PKI, certificates, crypto, and permission models across all the platforms he uses (and keep up to date on those too!)
Users will not waste their time thinkin about trust. The history of our industry is ample evidence that it would be a losing battle. Not to mention a single mistake can be ruinous, requiring absolute perfection 100% of the time (from users and programmers).
One can hope that, eventually, formally mathematically verified open source systems will help solve the issue, at least on the programming side.
Edit: since this was downvoted, I will elaborate. The halting problem only applies to arbitrary programs on Turing-complete systems. It is possible to create useful systems that are not Turing complete. As a baseline example, it is easy to tell that the following Ruby program halts:
exit
Does society try to keep these people illiterate? Does we give up, accuse the millions of illiterate people of not caring, and find ways to hide important things from them? Do we simply let them stay ignorant while making sure we hide any books when they are around, because books when they are around "because they don't care"? While I'm sure there have been been people who have done these things, we - as a modern society - generally find the idea of being illiterate to be a serious problem; serious enough that we spend significant amounts of money on education programs and other attempts to fix the problem of illiteracy.
Technology has created a new literacy. I'm not talking about programming or suggesting that people need to know HTML or anything. However, if you want to function in modern society, you need to understand some of the evolving language that society uses. This new literacy includes things like understanding that strings of the form "xxx@yyy.zzz" are probably an email address, and when you read something that starts "http://" or ends in ".com" or ".net" is probably referring to a website. The fact that the educational system has yet to catch up to the changes in technology is not a reason to force decisions on people, nor is it a reason to accuse them of not caring; instead, we should be interpreting the problems people have with security as a sign that a lot more education is needed, and we need to find ways to help people learn so they can protect themselves.
Unfortunately, there are a lot of people in the tech community that are confusing "frustration at not understanding obtuse technology" with "not caring about security". Many people do care, but lack the slightest idea about how to even approach important technical decisions. Certificates, keys, signing, and the like are not what matters, and are minutia tha should be left to those with proper technical knowledge. What matters in security is where the trust is being placed, and that is something a lot of people are skilled at.
Obviously, change isn't going to happen overnight. My suggestion is that we need a way to let people at least start down that path of managing trust. A good first step would be simply exposing the process so people can learn that a trust decision is even necessary.
[1] functionally illiterate is defined as those adults with a reading level below the basic requirements necessary to "perform simple and everyday literacy activities". Data is from https://nces.ed.gov/naal/kf_demographics.asp
That's like saying they are bad at juggling with one hand while riding a unicycle. Passwords are the bad thing, and users have been subjected to them for quite long enough.