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. - Matt _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
