On 27/09/2016 09:31, Kurt Roeckx wrote:
On 2016-09-27 01:18, Jakob Bohm wrote:
It would perhaps be useful if you could dispute, using Firefox as an
example, and considering the real deployment (not the theorhetical
abstract of ways in which someone 'might' configure about:flags, but
no one can and still have the same experience), the following points:
https://www.imperialviolet.org/2011/03/18/revocation.html
This tells me that Firefox OCSP defaults are *insecure* and reaffirms
my impression that Firefox has completely dropped the ball on CRL
handling (Since the security-on setting is for OCSP only).
It also claims (with apparent evidence) that other browsers are
similarly lenient by default, which is a surprise.
You should really try and set the OCSP check to mandatory, connect on
many different networks, and then see how many times it breaks.
I don't have access to that many networks, the ones I mostly use are
set up to allow OCSP and CRL checks against the CA urls.
For instance when you connect to a captive portal and it does https it's
very likely that the OCSP check will fail.
If a captive portal prevents the browser from checking if the captive
portal's own certificate is revoked, then the browser should tell the
user (so the user can decide), not pretend that all is OK.
We really want OCSP stapling.
Unfortunately, you are not going to get it anytime soon, and users need
to be protected from revocation interference 20 years ago (when SSL was
introduced by Netscape), not in some future wishful scenario.
Also note that automatic CRL downloading before expiry (as specified in
the CRLs themselves) would be robust against temporary outages because
they don't become invalid until some time after the browsers should
start attempted downloads.
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