CertSentry preview

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. :slight_smile:

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. :slight_smile:

Once 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:

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.

Thank you everyone for helping us!

Lets fix revocation together!


Very interesting read indeed. This is a great step forward for comodo. i will try this out once im done with school.

just out of curiosity how is this going to be implemented into cis?


CertSentry is a separate software component, so “bundled with CIS” might be a better description. CertSentry aspires to provide system-wide protection against the next generation of attacks on CAs and PKI, which fits well with the system-wide protection offered by CIS.

Of course, if we think of ways in which it might make sense to more closely integrate CertSentry with Dragon and/or CIS, we will certainly explore the possibilities.

Thanks Rob :-TU
Let’s fire up a VM to see how it does :slight_smile:

thanks i understand for some reason i thought it was implemented in dragon not a separate component.

thanks for the response

And I turned it on… and Just got a alert…

[attachment deleted by admin]

Which could also mean, that you block traffic on port 80 for “wlmail.exe”. Or is “wlmail.exe” the signed file and you block traffic on port 80 for “svchost.exe” or “explorer.exe” or…??

By the way, can I download CertSentry as a single download without dragon?

No CIS is set to allow all out on Safe Mode… so it wasn’t blocked.

And currently no.

A great application to experiment with.

Will this program send Comodo stats automatically to build up a database to work with?
How are you collecting information to use for full product development?

When you say “turned it on” … how? I can’t find an option to enable or disable it.

To enable “hard-fail” only for certificates issued by Comodo’s CA system:
To enable “hard-fail” for all certificates from all CAs:
HKEY_LOCAL_MACHINE/SOFTWARE/COMODO/CertSentry/DefaultFailureMode (value “2”)

How can I see it is running? Does it run as a service or executable?

I don’t see any executable or services for it… maybe its svchost.exe related…

Your unlikely to see anything running additionally to the browser, as it’s just an added option to what’s already there. Basically, it’s just a way of telling the browser how to behave when there’s a failure to contact and OCSP server. Instead of a soft fail, use a hard fail.

The reason for this particular alert is that Microsoft, for reasons best known to themselves, failed to include any revocation server URLs (i.e. CRL Distribution Points and/or Authority Information Access->ocsp) in their “Microsoft Code Signing PCA” CA certificate.

So it wasn’t the case that CertSentry attempted this revocation check and it failed. Rather, CertSentry couldn’t even attempt it!

After a bit of googling and URL-guessing, I’ve found the missing CRL:

I think I might add a “missing CRL URL” list to CertSentry, so that it can perform revocation checking in scenarios like this.

That’s purely a strategical decision. Technically, CertSentry can be installed on its own. If we ever change this strategy, we’ll let you know.

Thanks. :slight_smile:

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 <AppData(Low)>/COMODO/CertSentry.
On Windows XP, this is likely to be…
C:\Documents and Settings<USERNAME>\Local Settings\Application Data\COMODO\CertSentry
On Windows Vista/7, this is likely to be…

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…

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:

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.

Please make sure that if you add the keys for hard-fail you make REG_DWORD keys else it won’t work.