5

Everyone seems to agree that it is REALLY important to protect private keys so the encrypted Internet can remain just that (see for example at How do certification authorities store their private root keys?). Yet, according to www.grc.com and other sources, many browsers, especially mobile ones, do not check sites for revoked certificates due to compromised keys or any other reason (see https://www.grc.com/revocation.htm). Even the new mobile version of Firefox for iOS does not seem to check if the site's certificate is revoked.

My question is very simple: why is this situation tolerated? It would seem to be important, especially with the increasing popularity of mobile browsers supporting e-commerce...

Community
  • 1
Stone True
  • 2,032
  • 2
  • 18
  • 25
  • 3
    Because users get annoyed if they cannot connect to Facebook, their bank, or whatever. User satisfaction is unfortunately considered more important; especially as most certificate issues are because the owner forgot to update it and it gets done within a day or two. i have set my browser to block those sites, and every some month I have to call a bank or other company and ask them to update their certificate or I will change to the competition, and typically it gets done within a day (maybe it would have been done without me calling too). – Aganju Dec 28 '15 at 03:42

2 Answers2

6

Checking for revocation is easy. But deciding what to do upon failure is not.

On the site you linked Steve Gibson writes:

Much of the certificate revocation system is badly broken and doesn't actually work!!

Yup.

And further down he writes:

Good and complete solutions DO exist.

And I don't think that's so. Unfortunately he doesn't go into more detail.

As far as I understand it comes down to the decision of what to do if the revocation check does not yield an answer but just times out.

  • Do you then err on the side of caution and deny access to the site ("hard fail")?
  • Or do you err on the side of "well networks are flakey sometimes" and allow access, perhaps after a click-through-message ("soft fail")?

If there actually is an attack against you with a revoked cert, then the attacker will probably control the network anyway and just block communication to the revocation checking server. This is a conceptual shortcoming in revocation checking.

Some ways around the issue with different approaches are:

  • OCSP must staple extension
  • short lived certificates

Further reading

StackzOfZtuff
  • 17,923
  • 1
  • 51
  • 86
-1

Revocation is truly heinous. And usually what happens is an os update manually removes them from the browser itself, as opposed to the browser removing it through some form of revocation list. I think these days the browser update also updates/removes the browser certs.

m2kin2
  • 89
  • 2
  • I think you're thinking about revoking a *root CA*? In that case you have to patch the software. There is no regular process to revoke roots. But GRC was worried about the failure of browsers to detect revoked *end entity* certificates (the opposite end of the chain of trust), I think. And there are mechanisms in place (namely largely CRL and OCSP) it's just that they're not really used (or completely useful). – StackzOfZtuff Dec 29 '15 at 08:41