On 10/13/2009 07:31 AM, Rob Stradling wrote:
> Gerv, have you read the current "security.OCSP.require in Firefox" thread on
> mozilla.dev.security?
>
> Daniel Veditz said yesterday...
> "An alternate approach I'd like to lobby our front-end guys on would be
> to put up a scary red bar when we can't validate OCSP. Users can still
> get to their sites so they won't ditch us for another browser, site
> owners are still getting traffic so they won't be breathing down _our_
> neck (too much), but the site will look a little scary and link to an
> explanation so site owners can take the issue up with their CA and users
> have the opportunity to decide not to submit sensitive data over the
> connection."
>
A warning would make DoS style attacks less attractive.
>
> So rather than just "OK" and "Not OK", I'd like to see 3 categories:
> 1. OK. Continue to download and display the webpage.
> 2. Maybe OK. Display a warning message about problems with the response
> from,
> or problems accessing, the CA's OCSP Responder. Continue to download and
> display the webpage.
> 3. Not OK. Display a message that the certificate is revoked. Block access
> to the webpage.
>
Internally the pkix processing keeps three states: revoked, known good,
and unknown. Failure to connect to the OCSP responder is treated as
unknown (as well as an OCSP response which explicitly says 'Unknown').
The pkix processing has a very complex set of processing rules that tell
it how to treat an overall unknown response.
The problem is pkix is processing a chain of certificates trying to give
you the answer "is this chain good". There are more reasons for a chain
to fail than simply revocation.... and there can be more than one cert
that is revoked.... and there can be more than once source of revocation
information (pkix will also try to fetch CRLs if OCSP fails).
That being said, you may be able to implement this policy as such
(warning this is pseudo code -- spellings are made up, not actual NSS
spellings, but the basic functionality is there):
status = PKIX_VerifyCert(.... revocation_policy_strict ....);
if (!status & reason == revoked) {
status = PKIX_VerifyCert(.... revocation_policy_best_effort ....);
if (status) {
set_revocation_warning(.....);
}
}
/* continue processing */
I believe the corner cases will still old here, the bigger risk is that
you somehow process a different chain in the latter case (though I'm
currently not able to construct one that presents an attack*). We should
walk through all the scenarios to make sure this is safe.
-----------------
* The closest I've come is this: A certificate with no AIA or CRLDP
extension issued by a revoked intermediate CA. Attacker blocks the OCSP
responder for the intermediate CA. The first call fails because the user
cert has no way of providing revocation information. The second succeeds
because the attacker has blocked our revocation information. But the
result is still exactly what we guaranteed the user. We would get the
page with the revocation warning. The surprising thing for the user is
they get the same warning whether or not the intermediate was revoked,
but that fits within the policy we've defined... and it is a bit of a
corner case.
> "Maybe OK" would be treated as "OK" if "ignore the problem" is selected, or
> as "Not OK" if "treat the certificate as invalid" is selected.
>
> I would treat No Response, 400 response, 500 response and "tryLater" as
> "Maybe
> OK"s.
>
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
