On 04/12/2015 11:19, Kurt Roeckx wrote:
On 2015-12-04 02:55, Jakob Bohm wrote:
How huge and unwieldy are CRLs really, especially if letting the
computer (NSS/Firefox) do the updating?
Individual CRLs are in the range of a few kB to a few MB. For the CA
that issues the subscriber certificates they have a maximum validity of
10 days but should be updated at least every 7 days.
The problem is that you want to check that CRLs before you send anything
to that site, so either you need to download that CRL during the
handshake, delaying the whole thing, of you would need to download all
the CRLs beforehand and update them regularly.
If you want to download them before you connect, you have a problem that
you don't know them all. You only know about the root CAs, not the
intermediate ones. But you do cache the intermediates that you've seen.
You know the ones for all the certificates you have during validation,
because each certificate lists all the applicable URLs directly. Root
CA certs only list the (optional) CRL whose sole job is to self-revoke
the root itself in worst case scenarios. This CRL may or may not be the
same URL as the CRL that is used to revoke directly issued certificates.
Downloading for all the intermediates would be in the order of several
GB a week that you need to download.
As for timing, there is the bootstrap problem of slowing down the first
connection needing a specific CRL (whose URL may not, in general, be
known in advance), but subsequent connections to certificates pointing
to that URL can use a cached CRL, which is preemptively updated at the
first few "update by" times until N such downloads have been done
without any reuse of that CRL. Thus for a typical user surfing mostly
sites signed by the biggest 3-4 CAs plus 1 or 2 regional CAs, the
weekly update would be limited to those (and only to those subCAs
actually referenced).
If all relevant browsers (I suspect NSS is or was the last holdout)
supports v2+ CRLs with extra attributes in them, then the CA can
publish delta CRLs to greatly reduce the per-refresh download size.
If a still relevant browser supports only the original v1 CRL format,
the CA cannot include the attributes needed to protect against MitM
attackers duplicating one of the CRLs (master or delta) for the other
to hide that the attacker is using a revoked certificate listed only in
the thus suppressed CRL. This in turn is because it is legal (and
good) for a certificate to provide redundant URLs for the same CRL, so
the browser cannot object to discovering that multiple listed URLs
point return the same CRL, unless that CRL contains a v2+ extension
attribute saying it should only be returned from one of the other URLs.
With proper delta CRL support across browsers, it might also be
possible (I think) for a huge CRL to be split into multiple layers:
A master updated every few months, a medium delta updated weekly and a
minimal delta updated daily (or even hourly).
Of cause all the technical details are in the relevant official
specifications from ITU-T, RSADSI and IETF.
Enjoy
Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
_______________________________________________
dev-security-policy mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-security-policy
