

Chrome/Firefox aren't checking CA revocation lists - fastest963

Chrome isn&#x27;t checking revocation lists anymore (source: https:&#x2F;&#x2F;www.imperialviolet.org&#x2F;2012&#x2F;02&#x2F;05&#x2F;crlsets.html) so for everyone reissuing keys today, their sites are still vulnerable for Chrome users, right?<p>I checked Google&#x27;s own (custom) CRL and they don&#x27;t have any serials from Comodo or Verisign&#x27;s revocation lists, but they do have some from GoDaddy. Verified with https:&#x2F;&#x2F;github.com&#x2F;agl&#x2F;crlset-tools.<p>Update: Added Firefox to title based on mbrubeck&#x27;s findings.
======
agl
In order to attack an HTTPS connection, the attacker has to have MITM position
against the victim: the ability to intercept TCP connections.

Such an attacker can obviously also block the CRL/OCSP lookup if one is made.
Even with revocation checking enabled, no browser that I know of will fail a
TLS handshake if the revocation check is blocked.

(You can configure Firefox to do this. Tools -> Options -> Advanced ->
Encryption -> Validation, check the box for "When an OCSP server connection
fails, treat the certificate as invalid" \- so says
[https://wiki.mozilla.org/CA:OCSP-HardFail](https://wiki.mozilla.org/CA:OCSP-
HardFail))

I claim that soft-fail revocation checking is basically nonsense. That's the
point that I'm making in
[https://www.imperialviolet.org/2012/02/05/crlsets.html](https://www.imperialviolet.org/2012/02/05/crlsets.html).

Making it hard-fail isn't viable: it makes OCSP servers a single point of
failure for huge parts of the web. That's why Chrome has a CRLSet system that
actually can achieve real goals. The attacker has to persistently MITM the
client in order to block the CRLSet update.

The CRLSet is limited in size. I had hoped that CAs would use the reason code
mechanism in CRLs to remove the "administrative" revocations that dominate
their CRLs. (Those are revocations where there's no suggestion of compromise.)
Some do, but most don't.

It's not true that the CRLSet doesn't include any Comodo or Symantec (who now
own Verisign's old CA business) CRLs. In fact, Symantec/Verisign CRLs are the
biggest contributor to the CRLSet.

But it's true that the CRLSet is limited in size. We focus on CRLs for CA and
EV certificates. I don't think the world has a great answer to the revocation
problem when certificates are valid longer and longer periods.

~~~
derefr
Would it be feasible to make OCSP errors abort the TLS connection if it only
applied to sites that have requested HSTS?

~~~
agl
We did this by mistake once and got bug reports about PayPal being flakey.
(PayPal was an early HSTS adopter.)

~~~
fastest963
Understandable, admins would just have to start treating OCSP like they do DNS
(if it fails you can't visit site).

~~~
derefr
A thought: given that admins already have something that they treat like DNS--
which is to say, DNS--could certificate revocations be distributed as DNS TXT
records, and thus reuse all the caching infrastructure DNS currently implies?

~~~
is39
I think this would be a good approach on many levels.

It appears there is already an (expired?) internet draft for this:
[https://datatracker.ietf.org/doc/draft-pala-rea-ocsp-over-
dn...](https://datatracker.ietf.org/doc/draft-pala-rea-ocsp-over-dns/)
[http://tools.ietf.org/html/draft-pala-rea-ocsp-over-
dns-00](http://tools.ietf.org/html/draft-pala-rea-ocsp-over-dns-00)

But i could not find any browser support or even plugins.

I guess all current development is behind DANE and/or multi-OCSP-stapling;
second one has some chance of being deployed soon.

[https://bugzilla.mozilla.org/show_bug.cgi?id=611836](https://bugzilla.mozilla.org/show_bug.cgi?id=611836)
[https://datatracker.ietf.org/doc/rfc6961/](https://datatracker.ietf.org/doc/rfc6961/)

\--igor

------
mbrubeck
Current versions of Firefox also do not use CRL, if I understand correctly. It
seems most modern browsers prefer OCSP instead, with CRL only as a fallback or
not at all. You can find some of the rationale at these links:

[https://mail.mozilla.org/pipermail/firefox-
dev/2013-April/00...](https://mail.mozilla.org/pipermail/firefox-
dev/2013-April/000329.html)

[https://mail.mozilla.org/pipermail/firefox-
dev/2013-May/0003...](https://mail.mozilla.org/pipermail/firefox-
dev/2013-May/000334.html)

[https://en.wikipedia.org/wiki/Online_Certificate_Status_Prot...](https://en.wikipedia.org/wiki/Online_Certificate_Status_Protocol)

[https://wiki.mozilla.org/CA:ImprovingRevocation](https://wiki.mozilla.org/CA:ImprovingRevocation)

~~~
fastest963
From my understanding of the source I posted they're removing OCSP support as
well: "There are two protocols/formats involved: OCSP and CRL, although the
differences aren't relevant here."

------
joeyh
I'm hoping to see a chrome extension that flags every certificate issued
before 2014/04/07 as insecure. In the meantime, I am switching to firefox to
use certificate patrol for anything I care about.

~~~
dfc
Who are you and what did you do with the real joeyh? The real joeyh hopes for
a chromium extension and switches to iceweasel in the interim.

------
asmeurer
[https://code.google.com/p/chromium/issues/detail?id=361230](https://code.google.com/p/chromium/issues/detail?id=361230)

~~~
asmeurer
The Chromium team seems to have an all-or-nothing policy when it comes to
security. c.f.
[https://code.google.com/p/chromium/issues/detail?id=53](https://code.google.com/p/chromium/issues/detail?id=53)

~~~
fastest963
For that bug at least they're now forcing the OS login before looking at the
passwords in the Settings page. Not perfect but something.

------
nav1
Yes it does. It's just not enabled by default.

~~~
fastest963
How many people are going to check that box under "Advanced Settings"? 0.1%?

~~~
scrollaway
Unlikely to be that high. The 0.1% that may dig in those advanced settings is
likely the same 0.1% that disabled the thing back when it was enabled by
default. CRLs are worthless.

~~~
iancarroll
How are they worthless?

~~~
msherry
They're worthless because clearly no one is using them. They may theoretically
be useful, but it doesn't matter if they're never put into practice.

~~~
iancarroll
Do you mean nobody on the CA side or the end user side? CA's suspend
certificates all the time - instant e the scam site had theirs pulled a few
weeks ago...

