the_simple_computer

Comodo CertSentry

This site is no longer being maintained so anything below could still be accurate, or very outdated.


Everything below is taken from this thread on Comodo's forums. Since it can not be accessed without first creating an account, here are the helpful posts about CertSentry by moderators and Comodo staff.

February 07, 2012, 03:12:59 PM

Last year's high-profile attacks (apparently by state-level adversaries) on several commercial CAs made our industry painfully aware that certificate revocation checking, as currently implemented, is ineffective. We should expect further attacks and we need to raise our game to defend against them. According to PKI theory, revoking a mis-issued certificate should be enough to protect users, but in reality this isn't currently the case. Most browsers "soft-fail" online CRL/OCSP checks, which means that an attacker can thoroughly defeat the protocols.

As you might expect, Comodo have been advocating that the browsers should begin to "hard-fail" revocation checks ASAP! But the browsers continue to resist such suggestions. They argue that online revocation checks can be slow and they fail too often, due to a varieties of reasons, not all of which are within the control of the CAs.

Rather disturbingly, Google have just gone one step further in the wrong direction (in our opinion): They have just announced their intention to make Chrome stop performing online revocation checks altogether. They want to replace realtime online checks with a proprietary mechanism that uses Chrome's automatic update system to push partial lists of revoked certificates to each Chrome user. This would mean that 100% of Chrome users will have no protection against a (probably vast) number of revoked certificates!

We remain unconvinced that online checks are, or necessarily need to be, as bad as the browsers frequently claim. In our opinion, what we need now are cold, hard statistics that reveal just how slow online checks are and just how often they fail.

Enter CertSentry. :-)

We have grand plans for CertSentry (much more than tackling the problems with traditional revocation checking), but the main function of version 1 will be to gather extensive statistics on the health of the current revocation checking infrastructure. We are confident that these statistics will prove invaluable to our efforts to "fix" revocation checking!

Our plan is to roll out CertSentry first to all Dragon users and then to all CIS users. But right now, we need your help to beta-test it by installing Dragon Beta version 17.2.0. :-)

nce installed, CertSentry is invoked whenever you run any application that uses the standard Microsoft CryptoAPI functions to perform revocation checks. Such applications include Dragon, Chrome (for now, at least!), Internet Explorer, Outlook, etc.

This CertSentry beta also has experimental support (disabled by default...for now) for "hard-failing" online revocation checks. If you would like to switch this feature on, simply add one of the following values to your Windows registry: (This needs to be a REG_DWORD)

To enable "hard-fail" only for certificates issued by Comodo's CA system:

HKEY_LOCAL_MACHINE/SOFTWARE/COMODO/CertSentry/COMODOFailureMode (value "2")

To enable "hard-fail" for all certificates from all CAs:

HKEY_LOCAL_MACHINE/SOFTWARE/COMODO/CertSentry/DefaultFailureMode (value "2")

Feedback greatly desired. We believe the code is stable, but please let us know of any repeatable host application crashes that don't occur with CertSentry not installed. Also, if you try out "hard-fail", let us know how you fare.

* * * * *

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.

* * * * *

Yes, CertSentry sends stats to Comodo automatically. I imagine that some folks will now be thinking "This is a privacy violation, just like OCSP!", so let me set your minds at rest: By default, CertSentry's stats don't reveal the End-entity Certificate (unlike OCSP); only the Issuing CA Certificate is revealed. This will be enough information for us to compare and contrast the relative performance and availability of each CA's revocation servers. My (optimistic) thinking is that if just one CA's revocation servers are operating with good enough performance and availability, then it is conceivable that all CAs could manage the same quality of service (given enough incentive!)


As currently configured, each CertSentry client sends its logs to the CertSentry server every 24hrs. So you've got a chance to look at what we're logging, if you'd like to.

Log files are stored in /COMODO/CertSentry.

On Windows XP, this is likely to be...

C:\Documents and Settings\\Local Settings\Application Data\COMODO\CertSentry

On Windows Vista/7, this is likely to be...

C:\Users\\AppData\LocalLow\COMODO\CertSentry

The local/network service accounts will also generate log files sometimes, and these tend to be stored in the "systemprofile" AppData(Low) directory.

On Windows XP, this is likely to be...

C:\Windows\system32\config\systemprofile\Local Settings\Application Data\COMODO\CertSentry

On Windows 7, this is likely to be...

C:\Windows\system32\config\systemprofile\AppData\LocalLow\COMODO\CertSentry

If you've got any concerns about any of the data fields we're logging, please let us know here. Thanks.

I think it's likely that a future CertSentry release will provide an opt-in mechanism for acquiring lots more data (of the personally-identifiable sort). Even if only a minority of users were to opt-in, the data gathered would probably still prove invaluable to our research.

* * * * *

CertSentry is registered with CryptoAPI as the default "revocation provider". Here's a doc from Microsoft if you're interested in more of the technical details:

http://msdn.microsoft.com/en-us/library/ms995348.aspx

The host application loads certsentry.dll into its process space (unless it's already loaded) whenever the host application requests a revocation check. There's no service and no separate executable.

* * * * *

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".