Google Researchers Propose Plan To Fix CA System 91
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."
Re: (Score:1)
Re: (Score:2, Insightful)
Re: (Score:1)
Re:Not Impressed (Score:4, Funny)
Re: (Score:2)
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..
Re: (Score:1)
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
Re: (Score:3)
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.
Re: (Score:2)
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.
Re: (Score:1)
I find your faith in authority disturbing
Re: (Score:2)
Re: (Score:1)
If it is arbitrary, why doesn't it vary across country in a completely random distribution from 1 to (say) 70?
Re: (Score:2)
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.
Re: (Score:2)
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).
Re: (Score:2)
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.
Re: (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.
Re: (Score:2)
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",
Re: (Score:2)
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.
Something To Think About (Score:1)
Re:Something To Think About (Score:4, Informative)
Re: (Score:3)
Which is exactly what browsers should do. But that doesn't solve the problem of CAs that can't keep their root keys secure.
Re: (Score:1)
Re: (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.
Re: (Score:2)
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
Re: (Score:2)
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
Re:Something To Think About (Score:4, 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.
Re:Something To Think About (Score:5, 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.
Re: (Score:3)
In 2005 I published a paper [acsac.org] 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.
Re: (Score:2)
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)
Re: (Score:2)
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)
Re: (Score:3)
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
Re: (Score:2)
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
Re: (Score:2)
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
Re: (Score:2)
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?
Re:Something To Think About (Score:4, Interesting)
DNSSEC is unpopular with governments because it breaks censorship.
Re: (Score:1)
Possible, yes. It's also a terrible idea: http://blog.thoughtcrime.org/?sort=&search=dnssec
Re: (Score:2)
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.)
Not a bad idea (Score:2, Funny)
Did anyone else read this as "Google plans to fix California"?
No? Oh well.
Re: (Score:1)
Re: (Score:2)
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)
Re: (Score:2)
Ha! This was my first though.
(Note to editors: Define your abbreviations or lose your audience.)
Re: (Score:2)
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.
Re: (Score:3)
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.
Maybe no Doctor in this world... (Score:4, Funny)
But that would admittedly be a pretty boring episode. And not the sort of thing he usually worries about.
It's like that old saying about regexes... (Score:5, Funny)
"Bob has a problem requiring secure communication. He decides to use certificates. Now Bob has two problems."
Re: (Score:2)
+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.
True story (Score:5, Funny)
Re: (Score:1)
Step missing: spend 3 years in beta
Self signed certs. (Score:4, 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."
Re:Self signed certs. (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.
Re:Self signed certs. (Score:5, Insightful)
Re:Self signed certs. (Score:4, Insightful)
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.
like the CA system, DNSSEC has its own authorities (Score:2)
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 [ietf.org]", lists among several weaknesses:
more on choice... (Score:2)
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.
Re: (Score:3)
DNSSEC is signed by CAs. If an attacker can compromise a CA, they can compromise DNSSEC.
Re: (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
Doesn't Fix Anything (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.
Re: (Score:2)
Re: (Score:2)
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...
Re: (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?
Not a fix (Score:5, 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.
Screw CA schme-A ... (Score:2)
An extra certificate sent to the browser (Score:4, Funny)
What are they trying to fix in California? (Score:1, Interesting)
And so comes a new market of clean history certs (Score:1)
Enter a blockchain (Score:2)
DNSSEC is not the answer (Score:2)
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.
Re: (Score:2)
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
Convergence (Score:1)
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.
So... (Score:1)
WikiCert? (Score:1)
Wikified certificates, anyone?