In the wake of the recent Comodo fraud incident, there has been a great deal of speculation about how to improve the public key infrastructure, on which the security of the Internet rests. Unfortunately, this isn’t a problem that will be fixed overnight. Luckily, however, experts have long known about these issues and have been devising solutions for some time.
Given the current interest it seems like a good time to talk about two projects in which Google is engaged.
The first is the Google Certificate Catalog. Google’s web crawlers scan the web on a regular basis in order to provide our search and other services. In the process, we also keep a record of all the SSL certificates we see. The Google Certificate Catalog is a database of all of those certificates, published in DNS. So, for example, if you wanted to see what we think of https://www.google.com/’s certificate, you could do this:
$ openssl s_client -connect www.google.com:443 < /dev/null | openssl x509 -outform DER | openssl sha1
depth=1 /C=ZA/O=Thawte Consulting (Pty) Ltd./CN=Thawte SGC CA
verify error:num=20:unable to get local issuer certificate
verify return:0
DONE
405062e5befde4af97e9382af16cc87c8fb7c4e2
$ dig +short 405062e5befde4af97e9382af16cc87c8fb7c4e2.certs.googlednstest.com TXT
"14867 15062 74"
In other words: take the SHA-1 hash of the certificate, represent it as a hexadecimal number, then look up a TXT record with that name in the certs.googlednstest.com domain. What you get back is a set of three numbers. The first number is the day that Google’s crawlers first saw that certificate, the second is the most recent day, and the third is the number of days we saw it in between.
In order for the hash of a certificate to appear in our database, it must satisfy some criteria:
- It must be correctly signed (either by a CA or self-signed).
- It must have the correct domain name — that is, one that matches the one we used to retrieve the certificate.
Accessing the data manually is rather difficult and painful, so we’re thinking about how to add opt-in support to the Chrome browser. We hope other browsers will in time consider acting similarly.
The second initiative to discuss is the DANE Working Group at the IETF. DANE stands for DNS-based Authentication of Named Entities. In short, the idea is to allow domain operators to publish information about SSL certificates used on their hosts. It should be possible, using DANE DNS records, to specify particular certificates which are valid, or CAs that are allowed to sign certificates for those hosts. So, once more, if a certificate is seen that isn’t consistent with the DANE records, it should be treated with suspicion. Related to the DANE effort is the individually contributed CAA record, which predates the DANE WG and provides similar functionality.
One could rightly point out that both of these efforts rely on DNS, which is not secure. Luckily we’ve been working on that problem for even longer than this one, and a reasonable answer is DNSSEC, which enables publishing DNS records that are cryptographically protected against forgery and modification.
It will be some time before DNSSEC is deployed widely enough for DANE to be broadly useful, since DANE requires every domain to be able to use DNSSEC. However, work is on the way to use DNSSEC for the Certificate Catalog well before the entire DNSSEC infrastructure is ready. If we publish a key for the domain in which we publish the catalog, clients can simply incorporate this key as an interim measure until DNSSEC is properly deployed.
Improving the public key infrastructure of the web is a big task and one that’s going to require the cooperation of many parties to be widely effective. We hope these projects will help point us in the right direction.
Hi Ben,
ReplyDeleteThanks for the useful information!
However, how is any of this substantially different than the publication of CRLs, which clearly didn't do anything useful in the Comodo certificate fraud?
PKI specified a distributed way of publishing CRLs but almost no-one bothers to check them. Why would they check any new database either? Will Google and Microsoft decide to agree to check the same database (for example?) or simply rely on their own methods?
Whether this facility is used remains to be seen, but both mechanisms described differ from CRLs, in that no-one has to notice anything is wrong for a certificate to get blacklisted.
ReplyDeleteAs for who will use our database and whether others prefer to do their own thing: this is not a competition. We will offer this service freely for anyone to use. It is up to them whether to use it or not.
"It must be correctly signed (either by a CA or self-signed)."
ReplyDeleteAre you publishing the list of CAs you recognize?
Conversely, though, this doesn't let you revoke a previously-seen and previously-valid cert once it becomes stolen. Google--and the other browser vendors--must also do their part to encourage websites and CAs to properly implement CRL or OCSP by more strictly enforcing failures in the browser.
ReplyDeleteThis has advantages, as John said. But it's certainly not a _replacement_ for OCSP/CRL. What do you do when a valid certificate that was well-known by Google's crawler is stolen? You still need revocation, and this will only happen if browsers start more strictly enforcing revocation check failures. Until that point, it's a chicken-and-egg problem--website owners and CAs have little incentive to worry about reliably responding to OCSP checks because browsers are tolerant of failure, and browsers won't get strict about failure for fear of troubling users with false positives.
ReplyDeleteIf Google wishes to do the _truly_ right thing here, they must induce a little bit of short-term user pain in exchange for long-term security. This is a very clever complimentary measure, but I don't see how it replaces revocation.
This comment has been removed by the author.
ReplyDeleteSo would DANE DNS record make CA authorities useless, cus I'm all for that. Not having to pay $150 to godaddy would be great.
ReplyDeleteFirst of all I would like to agree that there is definitely a need for improvements in the PKI system.
ReplyDeleteThe post above is raising some questions in the role of Google:
1.> Does Google forget that if there where proper restrictions in the Comodo CA at the first place this incident never happened? (It was also not the first case with this particular CA)
Everyone could get hacked, if you have many RAs like with Comodo that you give full control the change is only much bigger! We have seen this in the past with RA that have issued false certificates without Comodo even noticed it.
It's not fare the blame everything on the hack or the failing PKI system.
2.> If Google is collecting SSL certificate information can you also do some general research as like what is done with the EFF SSL Observatory project?
3.> The wide implementation of DNSSEC would have a positive impact on security and brings a lot of opportunities for PKI. Google is one of the companies that could help to speed-up the implementation of DNSSEC by for example:
a. Creating a symbol in the Chrome browser (like the padlock) if there was a positive verified DNSSEC lookup and vice versa.
b. Something similar could be done near the results in the search engine.
Making DNSSEC visual to the end-user and website owners would definitely help to get a broader implementation.
Interesting approach. Is Google going to sign the TXT records with RRSIG once google.com gets the DNSSEC signature? (.com is signed, google.com is not yet signed)
ReplyDeleteIf an attacker is MitM-ing your connection to a site, he can be either "eclipsing" you or eclipsing the site. I'd say the "eclipsing you" (e.g. law enforcement) is more likely and then the attacker can just forge the TXT responses. Perspectives' answer is signed (i.e. attacker can only block them; though the distribution of Perspectives' public keys is "SSH known_hosts-like", no revocation either).
With "classic PKI" + TXT&RRSIG it amounts to getting closer to web-of-trust (now we have two hierarchies).
The DNSSEV Validator (www.dnssec-validator.cz) will get a support for Google Chrome soon as we have migrated from XPCOM to NPAPI, which allows us to support more browsers. Right now we are working on IE.
ReplyDeleteAnyway Ben, since you are co-author of CAA, do you really feel that the CAA would help in this particular case? Correct me if I am wrong, but the CAA proposal is a way of saying: "If you are nice, don't issue a cert" and if you don't get all CAs in the TA store, you gain no protection against rogue, malicious or hacked CA issuing a certificate for domain "protected" by CAA.
@Ondřej Having a DNSSEC Validator add-on for Chrome is nice, but this will not really help for a wide spread use of DNSSEC I think.
ReplyDeleteIt would be a huge step forward if Google would decide integrate a plugin like dnssec-validator.cz by default.
This doesn't seem useful for certificates with several SubjAltNames. An attacker could create a certificate for www.evil.com and www.ebay.com, use it on www.evil.com until it shows up in the TXT record with high numbers, and then use it to MITM connections to www.ebay.com.
ReplyDeleteThe TXT record should include the domain name for which the certificate has been seen (or at least a hash of the domain name).
One question about the Catalog's semantics - if a certificate is revoked, is it removed from the catalog?
ReplyDeleteThere are 2 easy solutions to make sure this Comodo scenario doesn't repeat itself...
ReplyDelete1. Use Extended Validation (EV) SSL, that shows the green bar and the actual organization's name that owns the domain the SSL is issued to. The process for verifying info in an EV SSL is manual and audited annually for each CA.
2. Browsers should NEVER trust any CA root that allows its resellers to do their own ownership validation for their SSL customers. This is gross irresponsibility and sheer laziness on Comodo's part to allow it in the first place.
Our site www.secure128.com processes thousands of SSL orders from various CA's annually and would never take on the legal responsibility of verifying domain ownership... isn't that what you pay the Certificate Authority to do in the first place??
Hi Ben,
ReplyDeleteGood idea! If you want this to be successful, please add a Chrome extension that automatically shows this data when you go to a site via SSL.
I've always wondered why browsers don't give you the option to warn you when a certificate for a site changes. Keep a cache, and if it's different, give the user options to react.
ReplyDeleteAny number of things can be done to help and/or give a gradation of how "bad" things are.
Cache-hit+Verified+Valid+No-CRL+etc == great
Cache-miss+Verified+Valid+No-CRL+etc == good
etc, etc
It Bothers me that the Military's SSL certificates have been out of date since 2001! Of course it might just be more secure to just keep your network locked down and secure in teh first place but What do I know. I want to be a SAN Storage mojo
ReplyDelete@Ramblings of a Nutty Swiss: the Certificate Patrol extension (http://patrol.psyced.org/) for Firefox does this, with some attempt to judge changes as "maybe ok". I have not seen what it looks like for detecting a "bad" cert change.
ReplyDeleteIf it is not DNSSEC signed, how do I know the response is not forged?
ReplyDelete@arkanoid The parent zone (.com) says if the child zone (google.com) is supposed to be signed.
ReplyDeleteDNSSEC does not have to be universally deployed to be useful now. The .com TLD and several other TLDs now support DNSSEC. So, some domain owners can enable it today. ietf.org, for example, is using DNSSEC. If the web browser would honor either the existing trust chain used by TLS today *or* the DANE records discussed in the article, then we could move forward. Why wait for the whole world to use DNSSEC before moving forward?
ReplyDeleteHi Ben, I just recently learned about the Google Cert catalog. When I tried it from shell I did not get the result (3 numbers) as you illustrated. Is the service still running? Can you point me to any updated info? Regards.
ReplyDeleteFor buying a certificate that suits your requirements, go through the features of each SSL certificate, assess your own needs and thereafter, decide.
ReplyDelete