On 04/04/2018 04:16, Matt Palmer wrote:
On Tue, Apr 03, 2018 at 03:16:53AM +0200, Jakob Bohm via dev-security-policy
wrote:
On 03/04/2018 02:35, Kurt Roeckx wrote:
On Tue, Apr 03, 2018 at 02:11:07AM +0200, Jakob Bohm via dev-security-policy
wrote:
seems
to be mostly justified as a poor workaround for the browsers and
certificate libraries not properly implementing reliable revocation
checks.
The problem is not in the libraries, or even the applications
making use of them, it's that actually trying to check them is not
reliable. There are just too many cases where trying to check it
results in an error.
OCSP stapling should at least help with this. We should really
encourage people to use this, and have software enable this by
default. According to ssl-pulse 31% of the sites enable it.
There might also be library or application bugs. At least firefox
for me is annoying that if it for whatever reasons fails, it says
it's an internal server error (which as far as I know is never the
case), and then even doesn't seem to retry it and just give that
same error again.
Most of the remaining 69% of servers run software libraries that don't
include a good enough OCSP stapling implementation. This includes the
omnipresent OpenSSL 1.0.2.
Automatically scheduled CRL downloads, though currently bandwidth
inefficient, would be much more reliable, as they are done and retried
in advance, with typically at least a day to recover from server
glitches. Also, CRL download servers are much more reliable than OCSP
servers as they don't need to run special software with high CPU
capacity and a secure private key, any basic redundant HTTP server can
do the job.
Delta CRLs, with some systematic enhancements, could further speedup CRL
downloads to a viable bandwidth level.
Bandwidth, whilst a big problem (not everyone has phat pipes, nor even
*always connected* pipes), isn't the only problem with CRLs. You also need
to be able to store them all, and generate and store the indexes to make
searching them sufficiently fast. Oh, and because CRL distribution points
aren't embedded in the root certificates, you're still going to stumble
across certs that you don't have the CRL for, which kills the "oh you'll
definitely have all the CRLs in advance" argument, bringing us back to the
same problem we've already got, that of "what do you do when you can't
access timely revocation information?" while *also* having all the other
problems of CRLs.
But the problem of a never-before or not-recently seen CRL will be a lot
rarer than the problem of a not-recently queried OCSP status, thus
representing a much smaller risk of either maliciously blocked checking
causing a fail open or unexpected damage from failing closed.
As for indexing, some requirements above and beyond the current RFCs
could make that a lot easier, for example:
- CRLs must be sorted by certificate serial number (DER sorting rules),
alternatively security libraries (like NSS) could create an index file
for each cached CRL.
- A combination of issuing CA and actual certificate signing algorithm
must have exactly one CRL, no sharding etc. allowed.
- Delta CRLs must contain enough data to allow the client to
deterministically reconstruct the latest CRL without actually
downloading it.
- CRL URLs must be listed in CCADB allowing participating browsers to
distribute an initial preload list, further reducing the frequency of
needing an uncached CRL. Alternatively define some other way for
clients to enumerate relevant CRLs.
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
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
