On 23/09/2016 17:27, Ryan Sleevi wrote:
On Friday, September 23, 2016 at 6:03:01 AM UTC-7, Peter Kurrasch wrote:
* Revocation: If a particular cert has been revoked for any reason, I should
be able to find that out so that I will know not to use it. Ideally this is
handled automatically in software but for various reasons it doesn't always
work out that way. I'm not sure if the manual tools are all that robust (or
exist?), but that almost doesn't matter because I'm dependent either way on the
issuer of the cert to issue the proper revocation. In the case of WoSign,
there are documented cases where certs were issued improperly. (I'm not sure
if we have documented cases where revocations were made improperly?)
Note: In pretty much all major software, automatic revocation doesn't work under an adversarial
threat model. That is, you can consider two types of misissuance: Procedural misissuance (perhaps
it states Yahoo rather than Google) and adversarial misissuance (that is, someone attempting to
impersonate). I'm handwaving a bit here, because it's more of a spectrum, but we might broadly lump
it as "stupidity" that causes insecurity and "evil" that causes insecurity.
Stupidity is important/relevant to trust decisions, to some extent. However, in practice,
I doubt you're examining each certificate presented to you on each connection *before*
you send data on that connection, which is what the CPS's are worded to suggestion, so
it's unlikely you're making major trust decisions on the basis that the certificate says
it was for "Yahoo"
So you're most likely concerned about 'evil' misissuance - those that an
adversarial attacker is attempting to gain access to your private
communications. And it's under this model that revocation doesn't work, due to
the attacker's ability to perform various exploits (such as blocking
communication to revocation servers, or stapling an OCSP GOOD response).
For this reason, I would encourage you not to think of Revocation as an
important factor of trust. I agree that you want to know if a certificate is
revoked in the abstract, and if we have reliable solutions that can help
facilitate that (e.g. OneCRL or CRLSets are more reliable means of revocation),
then great, but we're not at a place yet where revocation is an intrinsic part
of the secure connection establishment.
While Firefox in particular has had a *horrible* history of disabling
or not implementing basic revocation checks (case in point: at least
until recently, Firefox would *not* check CA issued CRLs automatically,
even though the URL to check is listed in the certificate being checked
and the renewal time is listed in the CRL itself), other browsers tend
to do them correctly, and they are nowhere as bad as proponents of
extreme centralization schemes claim.
For example OCSP stapled responses cannot be reused or abused beyond
their CA specified expiry times, 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.
Mechanisms such as OneCRL tend to be horribly incomplete. Just in the
past few months there has been repeated mention on this list of revoked
certificates that were not on OneCRL, only on the CA 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
