GRC's | SSL/TLS Certificate Revocation Awareness – The case for OCSP Must-Staple

Source:  GRC's | SSL/TLS Certificate Revocation Awareness – The case for OCSP Must-Staple

Security Certificate Revocation Awareness

The case for “OCSP Must-Staple”

The security of the Internet depends upon our ability to revoke lost, stolen,

or compromised certificates. But our ability to actually do so is badly broken!

Executive Summary

·     
The original public
key infrastructure (PKI) certificate revocation list (CRL) scheme didn't scale
as the number of certificates and inevitable revocations exploded.

·     
The online certificate
status protocol (OCSP), which was intended to replace the collapsing CRL
system, always suffered from design and deployment problems which compromised
privacy, reliability and security.

·     
For many years nothing
much happened. Neither system was usefully being enforced while stolen and
revoked certificates would or could typically be honored by web browsers. 44%
of certificate revocations are due to key compromise, so this failing is
important. But end users had no way of detecting what was going on, so the
problem never got the attention it deserved. “Revocation” was given lip
service, but the insiders knew it didn't really work.

·     
Several years ago the
idea for “OCSP Stapling” was adopted and implemented in web servers. Then, very
recently, by a few web browsers and client operating systems.

·     
But the whole system
was still set to “fail soft.” This allowed for an effective bypass of the
authentication it was attempting to provide. Because it could be argued that
revocation still didn't work, some web browsers continued to ignore it and
didn't even bother trying.

·     
Finally, the concept
of “Must-Staple” was born and took root. When this is implemented it will allow
web browsers to safely and reliably implement a “fail hard” policy. This will
finally deliver the certificate revocation security users always thought they
were getting, but never really did.

What's the problem?

The fundamental problem is that the Internet has outgrown the original system we are still trying to use. And rather than fixing it, the Internet industry has largely stopped using it . . . and hoped no one would

notice or care.

The original Certificate Revocation List (CRL) solution doesn't “scale” well. The
simple idea of a certificate revocation list is that the collected unique
serial numbers of any not yet expired but known invalid certificates are
maintained in a master list.

Each certificate authority publishes its own continuously changing list of the
certificates it has issued that have been revoked and are not yet expired. Each
issued certificate contains a URL link pointing to this list so that the
operating system or web browser relying upon the certificate's veracity knows
where to obtain the list for inspection.

This creates problems: Since certificates are being continually revoked, replaced or
invalidated for various reasons, the “true list” is a continually moving
target, and any copy of the list is out of date from nearly the moment it is
published. Certificate authorities update their published revocation lists
weekly. Since the certificate authority (CA) model is “trust unless proven
invalid”, this means that an aging CRL will not contain information of recently
revoked certificates, resulting in those certificates being erroneously trusted
when they should not be.

The obvious solution is to update the CRLs as often as possible. So already we face
a tradeoff in a system that, to be secure, should not have tradeoffs. The
question is how often to we update? The answer is complicated by the fact that
many certificate revocation lists are quite large:

Read complete article >>>