[cabfpub] Ballot 153 - Short-Lived Certificates
rbarnes at mozilla.com
Tue Nov 3 01:27:55 UTC 2015
On Tue, Nov 3, 2015 at 3:04 AM, kirk_hall at trendmicro.com <
kirk_hall at trendmicro.com> wrote:
> I’m puzzled by one argument of the proponents of Short-Lived Certificates
> (SLCs) with no OCSP revocation checking.
> They note that the Short-Lived Certificates have a validity period of 4
> days, and that OCSP responses must be updated at least every 4 days under
> BR 4.9.10 (but are good for up to 10 days). Because a Short-Lived
> Certificate will expire in the same time as the maximum update period for
> OCSP responses, then then make the logical leap that SLCs with no OCSP
> pointers are “just as good” as SLCs with OCSP pointers because [somehow]
> the SLCs with no OCSP revocation information will all expire *before*
> some users will ever learn they were revoked.
> It’s true that visitors to websites secured by a SLC who receive a “good”
> OCSP response, and who then return to the website before its revoked SLC
> expires, probably will not any receive updated revocation information
> because the first OCSP response is cached. But that’s the *only* case
> where the two SLCs (one with an OCSP pointer, and one with no OCSP pointer)
> are roughly the same from a user security standpoint. And that’s probably
> a very small minority of users who visit a site secured by an SLC over its
> 4 day validity period. The other users who visit the site after revocation
> over the same period would all benefit from OCSP revocation information.
> Suppose a website secured by an SLC is visited by 1,000 unique users per
> hour (not counting any repeat visits by any user – so leaving out the
> effect of a cached OCSP response) – that’s 96,000 visitors over the SLC’s
> validity period. Now suppose the SLC is revoked 6 hours after issuance due
> to key compromise or phishing. If the SLC has an AIA OCSP pointer, then
> OCSP revocation checking will occur for the 90,000 unique users who visit
> the website during the 90 hours after the SLC was revoked, and those 90,000
> users have a very good chance of receiving an OCSP revocation warning from
> the browser – that’s good user security.
You seem to be assuming that the presence of an AIA OCSP pointer will cause
the browser to do an OCSP query. That is false. Browsers will not make
the OCSP query in several situations, most notably: (1) If the browser has
a cached OCSP response, and (2) if the server sends a stapled OCSP response.
So browsers that have visited the site while the cert was still valid will
continue to use the cached response until it expires. And an attacker can
force new visitors to skip the OCSP check by sending the good OCSP response
as a stapled response.
> In contrast, if the SLC contains no AIA OCSP pointer and the 96-hour SLC
> is revoked after 6 hours, then *none* of those 90,000 users who visit the
> website after revocation have any chance of receiving an OCSP revocation
> warning. That’s very bad user security.
> It’s true that some OCSP queries are blocked or users receive no response
> – but that doesn’t mean it’s not work checking for revocation of a
> certificate via OCSP. Suppose as many as 10% of OCSP queries don’t receive
> a response – that’s still 90% that do, which would protect 81,000 of the
> 90,000 users in the example above. Without any revocation checking at all,
> those users are sitting ducks.
> Some have suggested the Short-Lived Certificates will only be used for 24
> hours on a website, then be changed out (although there is nothing to
> prevent the website owner from using the SLC for the full 96 hours of its
> validity period). OK, so in that case only 18,000 unique users would visit
> the site with a revoked cert for the 18 hours after revocation without
> being warned that the certificate was revoked – that’s 18,000 users who get
> no OCSP warning, again bad user security.
> To address this problem, the proponents of Ballot 153 have suggested that
> including a CDP pointing to a CRL is just as good as an AIA OCSP pointer
> for revocation checking. But that’s not true at all – as my prior email
> noted, most CAs use only one issuing sub-CA, and it only publishes one CRL
> covering all issued certificates. That one CRL can be valid (and will be
> cached by each user once received) for up to 10 days before it must be
> refreshed by the user. And that one CRL covers *all* Short-Lived
> Certificates and all other certificates issued by that CA to all FQDNs for
> all customers around the world – potentially millions of websites.
> So if a user visits Site A on Monday and downloads and caches the current
> CRL, that stale CRL will effectively block the user from ever receiving any
> additional revocation information about *any* other certificate, including
> SLCs, issued by the same CA for the next 10 days. Again, bad user security.
> After downloading the CRL on Monday, if the same user then visits Site B
> secured by a SLC from the same CA on Wednesday, and the site’s SLC was
> revoked on Tuesday, the user’s client will only check the [stale] cached
> CRL received on Monday – there will be no new revocation information listed
> on that stale CRL after Monday about the revocation of the Short-Lived
> Certificate on Site B on Tuesday. Clearly, a CRL is no substitute for a
> fresh OCSP response for each certificate with a unique serial number.
> This problem will only be exacerbated if the world moves to massive
> numbers of Short-Lived Certificates issued to massive numbers of FQDNs and
> websites around the world as part of the https-only push – in effect, all
> websites secured by SLCs from a single CA will be linked from a security
> standpoint, and users who access that CA’s CRL will only receive fresh
> revocation information about *all* the CA’s secured websites once every 10
> days. That’s not good enough. (Remember, most fraud, phishing, and
> look-alike sites do most of their harm in the first 48 hours after
> installing their certificate, so SLCs from major CAs with CRLs only will
> likely be very popular with them.)
> The recent academic study “An End-to-End Measurement of Certificate
> Revocation in the Web’s PKI,”
> http://www.cs.umd.edu/~dml/papers/revocations_imc15.pdf, notes in the
> summary to Section 9 that “over 8% of fresh certificates and almost 1% of
> alive certificates” are revoked – that’s a lot of revoked certificates out
> there that pose a threat to user safety.
> So *no*, the fact that Short-Lived Certificates have a maximum validity
> period of 4 days, and the fact that OCSP responses must be updated at least
> every 4 days, does not mean that a SLC with *no* AIA OCSP pointer is as
> good as a SLC *with* an AIA OCSP pointer from a user security standpoint –
> not true at all. The only thing the two standards have in common are the
> words “4 days.”
> There is rough security equivalence *only* for users who have visited a
> site and received a “good” OCSP response, and then re-visit the same site
> after revocation but during the same SLC’s validity period – but this has
> to be a very small percent of users.
> All certificates should include AIA OCSP pointers, including Short-Lived
> Certificates, to protect users. Some browsers may choose not to bother
> with revocation checking for SLCs, but others will and will protect their
> users. Any CA that issues Short-Lived Certificates without AIA OCSP
> pointer is putting users at risk unnecessarily.
> Let’s not go backward on the revocation security improvements the Forum
> has made over the past four years. In fact, we should start ratcheting
> down on the maximum validity period for current OCSP responses, from 4 days
> to maybe 2 days, for greater user security. We can help solve the OCSP
> response infrastructure problems of both browsers and CAs by aggressively
> promoting stapling and working with server makers to turn on stapling by
> default – that’s the right way to proceed.
> TREND MICRO EMAIL NOTICE
> The information contained in this email and any attachments is confidential
> and may be subject to copyright or other intellectual property protection.
> If you are not the intended recipient, you are not authorized to use or
> disclose this information, and we request that you notify us by reply mail or
> telephone and delete the original message from your mail system.
> Public mailing list
> Public at cabforum.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Public