On 9/6/11 11:07 AM, Devdatta Akhawe wrote:
> Sure. But I think users would be very surprised to find that every
> time they visit a SSL site, some server somewhere is noting down what
> site they visited, and when.
Yes, OCSP supposedly traded off a little privacy for immediacy over
CRLs. Except that many OCSP deployments in practice just respond
based on the data in the CRL.
The response is currently cached in memory so there's not currently
a "Private Browsing" mode concern (PB is not "anonymous" browsing,
we're just trying not to leave local traces). The OCSP server won't
know about every load, but probably could track your first visit of
the day. In order to improve reliability and privacy, however, we'd
like to implement on-disk caching of OCSP responses which does mean
we'll have to be careful around private browsing mode.
We'd also like to implement "OCSP stapling", where the website
you're visiting returns a recent signed OCSP response along with its
certificate. This improves privacy for users, reduces load on CA
infrastructure (the server checks OCSP once every few minutes rather
than every visitor checking), and improves the loading speed of the
website (browsers can just load the page, don't have to wait for a
separate OCSP response). The users privacy depends on the web server
implementing this, but there are some benefits to the server so we
have hope.
Another thing we'd like to do is prefer "local fresh" CRL data over
OCSP rather than strictly doing OCSP checks. With CRL a CA only
knows you're interested in some website they've issued a cert for,
not which one (well, a slimy CA could use a separate CRL per cert
but that would be noticed). The idea would be something like
- if we already have the CRL and it's not stale use it
- if CRL is missing or stale
+ use OCSP
+ also start downloading the CRL (which can be large)
for next time and for other sites using that CA
If we're checking in this manner and have stapling implemented we
probably have enough revocation reliability to be able to HARD FAIL
connections without an explicit revocation response. With that kind
of redundancy if we can't get a response you're probably under attack.
-Dan Veditz
_______________________________________________
dev-security mailing list
dev-security@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security
