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.
As 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.
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.
This 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.
If 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.
First of all I would like to agree that there is definitely a need for improvements in the PKI system.
The 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)
If 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.
Anyway 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.
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.
The TXT record should include the domain name for which the certificate has been seen (or at least a hash of the domain name).
There are 2 easy solutions to make sure this Comodo scenario doesn't repeat itself... 1. 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??
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.
Any 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
@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.
DNSSEC 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?
Hi 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.
Follow
23 comentários :
Hi Ben,
Thanks 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.
As 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)."
Are 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.
This 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.
If 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.
So would DANE DNS record make CA authorities useless, cus I'm all for that. Not having to pay $150 to godaddy would be great.
First of all I would like to agree that there is definitely a need for improvements in the PKI system.
The 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)
If 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.
Anyway 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.
It 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.
The 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?
There are 2 easy solutions to make sure this Comodo scenario doesn't repeat itself...
1. 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,
Good 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.
Any 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
@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.
If it is not DNSSEC signed, how do I know the response is not forged?
@arkanoid The parent zone (.com) says if the child zone (google.com) is supposed to be signed.
DNSSEC 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?
Hi 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.
For buying a certificate that suits your requirements, go through the features of each SSL certificate, assess your own needs and thereafter, decide.
Postar um comentário