Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Not really inconsistently. Firefox, Safari and IE all do this. Firefox, for example, will wait up to 10 seconds for an OCSP response (https://wiki.mozilla.org/CA:ImprovingRevocation)

That article cites Adam Langley - a respected engineer at Google who has worked on Chrome and parts of Go. Chrome is wildly lax with certificate revocation. Don't believe me? Browse to https://revoked.grc.com from Chrome. It is true that if someone can MITM they can block CRL/OCSP requests...but browsers (including Chrome) made the choice of 'soft-failing' and thus making it an attack vector. OCSP stapling and the proposed "OCSP Must-Staple" (https://tools.ietf.org/html/draft-hallambaker-muststaple-00) solve this problem. With all due respect to Adam, it seems a little peculiar to say revocation checks don't work when they're broken by design in the browser he worked/works on.

Chrome is the only browser that skips revocation checks for DV certificates but it still does OCSP for EV certs. Chrome has the concept of CRLsets - but these have been shown to only capture a very small portion (<1%) of revoked certificates.

Firefox has the option to hard-fail if the OCSP request isn't verified. This should be the default behavior, but the fear is that too few people understand this and would migrate to another browser if SSL secured sites randomly failed to load sometimes. Note: this is vastly preferable, in my opinion, to loading a site with a certificate of unknown status.



Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: