On 23/09/2016 18:46, Ryan Sleevi wrote:
On Friday, September 23, 2016 at 9:15:48 AM UTC-7, Jakob Bohm wrote:
they are nowhere as bad as proponents of
extreme centralization schemes claim.
Citation needed. It would seem that you're not familiar with the somewhat
well-accepted industry state of the art.
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.
https://www.imperialviolet.org/2012/02/05/crlsets.html
A nice example of the centralized thinking I was criticizing. For
example, your list of criteria for 3rd party CRL inclusion seems to
(as is typical of Google) impose Google-centric demands on CAs, while
arbitrarily excluding CRLs that try to revoke certificates that had
misencoded serial numbers in them.
https://www.imperialviolet.org/2014/04/29/revocationagain.html
Nice rant.
For example OCSP stapled responses cannot be reused or abused beyond
their CA specified expiry times,
No, but they can be omitted, and no client hard fails on the absence of OCSP.
Similarly, fetched OCSP can be blocked, under an adversarial model.
I cannot stress enough: discussions of revocation schemes require a model of
the attacker or the threat to have relevant discussions. Abstract notions,
however attractive, must be intersected with practical reality.
My point would be that I disagree with your assessment that being
lenient to failures to reach revocation URLs is acceptable browser
practice and your associated arguments about popularity effects.
For example, rather than arguing that CA-side url failure would induce
web site distrust in HTTPS seems to ignore the possibility it would
just induce similar distrust in the failed CA. Thus providing a
massive incentive for CAs to make their revocation distribution system
robust.
The revocation by non-payment of installments of Symantec is not much
of an argument, once you notice the counter-effects caused by the
reduced maximum certificate lifetime in new CA/B rules and the
emergence of cheap certificate providers such as Let's encrypt as an
alternative to buying certificates in installments.
while CA issued CRLs and delta CRLs
cannot be used beyond their scheduled expiry times. To bypass these
mechanisms an attacker would have to somehow manipulate the relying
party's clock and/or a trusted Time Stamping Authority. Or the
attacker could choose a CA with too long expiry times on their CRLs and
OCSP responses.
No. They just prevent them from being delivered. Which is trivial.
My arguments presumed secure browser defaults, not the "ignore failures
and pretend all is still secure" crap coding you have both uncovered
and worsened (by suggesting to turn off the check completely in Chrome).
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
