Oooh, good point. Sorry for failing to mention that.
This might be a n00b query for some but nonetheless -
How is this feature better or worse than some of the OCSP options present in firefox(about:config) additionally if the certificates aren’t revoked by their respective CA entities how’ll CertSentry work without any credible(unpublished) info ?
No, that’s actually a good question. Firefox does have a tickbox (disabled by default) for enabling hard-fail, so this is indeed a similarity with CertSentry. In fact, IIRC, this was one of the reasons why we opted to (first) make CertSentry work with the other major browsers (Dragon, Chrome, IE). To be honest, I’m not sure if Firefox is currently able to log any useful statistics on online revocation checking failures, but I do know that there exists no code for shipping those logs to Comodo for analysis. 
I mentioned previously that we have grand plans for CertSentry. Attempting to fix online revocation checking is just step 1. It’s also worth noting that online revocation checking is not the only technology that stands to win or lose in the “Is hard-fail viable?” debate.
For example, see this article - http://www.theregister.co.uk/2012/02/08/convergence/ - published only a couple of hours ago.
We are following developments in Convergence and other “fourth-party certificate evaluation” projects with interest, and we’re contributing to industry debate in various forums. We are advocating the creation of standards for “fourth-party certificate evaluation”, because we believe that this will help bolster (but definitely not replace) today’s “Internet Trust Infrastructure”.
Fourth-party certificate evaluation may will probably involve online checks, but without hard-fail these protocols could be defeated in just the same way as today’s soft-fail CRL/OCSP. Hence we see Moxie battling with Google too.
If a certificate is not revoked, the CA should still be issuing CRLs and/or OCSP Responses. The CRLs will simply not contain the serial number of the unrevoked certificate (implying that it is unrevoked), and the OCSP Responses will contain the status code “good” (meaning unrevoked).
Or if you’re enquiring about certificates that contain neither CRL URLs nor OCSP Responder URLs, then I think it rather depends on whether or not we can track down “credible” revocation information somewhere on the Internet. I covered one example of this (and the likely fix) that involves some Microsoft CA certificates, in an earlier post to this thread.
Analysis of the statistics should help us to discover the vast majority of CAs that fail to include revocation server URLs in certificates. This data would prove useful for getting these CAs to clean up their act.
Hate to sound like a broken record but where does proactive security, I’m assuming that’s what we all want but more importantly need it first & foremost, come into all of this ? It’s something similar to a zero day exploit except the fact that they’re much harder to implement especially on newer(win7) systems with a certain set of conditions to be met for the actual flaw to be exploited ! Incase of a digicert though things are different, one doesn’t encounter them very often & there’s an almost a 100% chance that when you’re visiting an insecure(compromised) site with a fake cert either your confidential info will/may be stolen or in the worst case scenario your connection could be compromised leaving you prone to remote attackers till you fix that gaping hole. So correct me if I’m wrong but isn’t there a way(like ever gonna be ?) to prevent the proverbial infection rather than looking for possible cures(in this case revocation lists) as might be the case here ?
The worry I have, at least for now, is fragmentation in the way crl checks are performed. I don’t think anyone is overly happy about the current mechanisms but having different ways of doing effectively the same thing, depending on which browser is used, also doesn’t bode well for the future.
Personally, I’ve been using convergence since last August, in fact I posted about it:
Something interesting for firefox users - A new way to deal with certificates…
It’s been very quite on my system but of course the main problem has been the lack of notaries. For all that It seems like a good solution. Certainly, a pleasure after setting OCSP to hard fail under firefox. Prior to that I was using Perspectives,
Now we have the proposal from the EFF for Sovereign Keys, Google deciding to do it’s own thing and now CertSentry. Of course, we mustn’t forget DNSSEC waiting in the wings, either.
I think it’s unrealistic to expect certificate mis-issuances to never occur, but there are certainly things we can do to reduce the likelihood of them occurring. For example, there’s currently no way for a domain owner to state that only certain CAs may issue certificates for that domain. Comodo have a proposal for addressing this problem: http://datatracker.ietf.org/doc/draft-ietf-pkix-caa/
Absolutely agreed. I’m hoping that the statistics we gather with CertSentry will prove conclusively whether or not it’s possible to improve online revocation checking technologies to the point where hard-fail becomes viable. Whatever we conclude, we’re hoping that our research will at least help to get the industry on to the same page and help to stop some of the “fragmentation”.
I think Convergence employs some level of redundancy, so if one notary is temporarily down the client will try to contact another one. In contrast, Firefox just makes a single attempt to obtain an OCSP Response: if hard-fail is enabled but the OCSP Responder cannot be reached…well, you’ve had it.
I’ve said to Google that I think they’re wrong to judge online revocation checks purely by their current implementation. We should attempt to figure out just how far online checks could be improved before even contemplating that they can never be good enough.
The other thing we’ve done to try to avoid “fragmentation” is to get the IETF to set up a new group (therightkey Info Page) for discussing Convergence, Sovereign Keys, etc, etc, with the intention of pooling all of the useful concepts into a set of standards. And we’re being proactive here as well. We’ve already circulated some draft proposals of our own for consideration.
also hardfail on specific CA is a good starting point.
for example, we would do our best to build out a good OCSP infrastructure to create a good user experience for hard fail. But at the moment you can’t select which CAs you can hard fail on etc…
melih
So will this pool of data(revocation lists & whatever else) be available elsewhere i.e. the general public or software specifically those for browser addons ? Also I tried this convergence addon(after seeing it mentioned here) alongwith https everywhere in FF but it somehow breaks the inbuilt OCSP & totally renders the browser useless at times btw its also got anonymx to go with the other(addons) two ! So before I’m accused of hijacking the thread the moral of the story is that too many addons will break any browser(more often than not) & being paranoid about online security is the last thing we need.
!ot!
I’ve not personally had any issues with Convergence, also being used with HTTPS Everywhere and HTTPS finder. I’m not sure what you’re referring to with “btw its also got anonymx to go with the other(addons) two”
I use anonymyx.net addon along with https everywhere but when I added convergence to the mix there seemed to be alot of problems while browsing like - secure connection couldn’t be made(to server), cert check check failed et al !
I’m not sure if I understand you. Are you asking if we plan to make public the statistics we will gather using CertSentry? We’ve not made any decision about this yet.
Yeah sort of, I mean this data could useful for online security in general plus developers could implement it(security features) with addons for various other browsers besides the ones based on chromium.
SSL is very old now…even the mullahs in Iran can block it…We need something new to replace it with
could someone please give an example of how google’s no online revocation checks, soft fail, and hard fail effects the user so that i can get some perspective on how serious this is
Ok, I’ll try to put it in a nutshell:
Online revocation check means: In the moment you’re visiting a website using https, your browser asks at the certificate authority: Is the used certificate still valid?
There are three possible results: yes, no and no answer
“Soft fail” means “no answer” is treated as “yes, the certificate is valid” (optimistic approach)
“Hard fail” in contrary means “no answer” is treated as “no, the certificate is invalid” (pessimistic approach)
Therefore, if the online revocation checking structure is not available (the CA is not reachable or the corresponding server is down), your secure connection will fail even if it is all right with the certificate if hard fail is used.
Not using online revocation means the browser comes with a database of revoked certificates. You don’t get the certificates status at the moment of visiting the secured site, but at the time when the database was generated/updated. But if the CA revokes the certificate after the database was built/updated, it will still be treated as valid.
To make it worse, every (trustworthy) certificate includes information, which server should be contacted for revocation checks. So online revocation checking works for all CAs. In contrary if Google doesn’t include revocation information of a CA in it’s database, revocation checks will always result in a valid certificate. That’s probably no problem for major CAs, but many companies, universities… have their own CA for internal certificates.
so if the CA is unavailable you won’t be able to reach the secured site period?
That depends on the browser implementation. Probably you would get a certificate warning and the possibility to override it if you really want to, as it is now for Internet Explorer or Firefox if the certificate is invalid.
Actually, Opera already implements a hard fail: The connection is treated as if it’s a default http connection if the certificate validation fails, while IE and Firefox show the padlocks. (I don’t know about Chrome or Dragon)
so if you say that you want to go through with it it will take you to the site without https even if say hypothetically it was a bank site
It will use https - and it’s “technically” exactly the same process as with the soft fail.
The question is “Is the certificate still trustworthy if it can’t be validated or not” or with other words “Should the browser notify the user if the certificate could not be validated or should it pretend all is fine”.