←back to thread

1318 points xvector | 1 comments | | HN request time: 0.21s | source
Show context
needle0 ◴[] No.19823806[source]
I’ll still keep using Firefox since I recognize the importance of browser diversity and the hazards of a Chrome monoculture (that and vertical tabs), but, yikes.

Still, this type of oversight seems all too common even in large companies. I remember several cases from Fortune 500 companies in the past few years alone. What would be a good way to automate checking for them? Has anyone developed a tool designed specifically to avoid certificate expiry disasters?

replies(18): >>19823825 #>>19823829 #>>19823831 #>>19823840 #>>19823848 #>>19823861 #>>19823913 #>>19823994 #>>19824009 #>>19824223 #>>19824243 #>>19824298 #>>19824668 #>>19824724 #>>19824795 #>>19824840 #>>19824927 #>>19825103 #
_wmd ◴[] No.19823848[source]
Let's not forget multiple mobile networks across Europe went down on the same day last year because Ericsson(?) let a cert expire on some internal management system that had not been updated. SSL cert renewal is one of the great unsolved problems in computer science

edit: not Europe, just UK and Japan apparently: https://www.zdnet.com/article/ericsson-expired-certificate-c...

replies(2): >>19823910 #>>19824709 #
AmericanChopper ◴[] No.19824709[source]
>SSL cert renewal is one of the great unsolved problems in computer science

Certificate expiry really only exists to make money for CAs. It doesn’t solve any security problem that CRLs don’t already solve (and solve better). There’s lots of unsolved problems relating to ‘how do you make a reliable PKI’, but cert expiry is really just an unrelated business requirement for CAs.

replies(4): >>19824751 #>>19824854 #>>19824875 #>>19825054 #
Beldin ◴[] No.19824875[source]
CRLs are not equivalent at all. They are a last-ditch effort to fix a problem when all else (expiry) has failed.

CRLs require maintenance and distribution of a list by a 3rd party. Creating an accurate, all-inclusive CRL of all website keys that your browser should reject is far, far from easy. (Case in point: "how many web sites are there?" Is not an easy question. )

Properly propagating such a list to any browser that might need it is another daunting task - less than 100% propagation means end users are exposed to security risks.

Certificate expiry is much more elegant: the client can check the certificate's validity himself, without relying on input from 3rd parties.

If certificates didn't expire, CRLs would (by now) be huge and growing enormously every day. They'd be so big that by the time you'd have downloaded one, it'd be outdated.

replies(1): >>19825048 #
tialaramex ◴[] No.19825048[source]
CRLs can be sharded, the cert carries the URL for the relevent CRL inside it. So they wouldn't need to have grown as huge as you suggest.

But, this sharing carries a cost for user privacy, if I shard certs 16 ways then each CRL download gives me 4 bits of info about which sites you were visiting.

OCSP effectively takes this to the extreme, each lookup is tiny because it's just for one cert, but it gives away exactly which cert you cared about each time.

replies(1): >>19825070 #
rocqua ◴[] No.19825070[source]
Besides leaking data by on demand CLR checking, you also have a difficult fail open v fail closed decision.

Failing closed means failure of a third party immediately breaks your site. Failing open means a MitM can simply block the CRL check.

OCSP stapling and the 'must staple' header are a lot better for privacy, and OCSP responses have some validity so at least a 5 hour outage of your CA doesn't bring your site down immediately.

It is still vulnerable to a DOS and trust on first use though.

replies(1): >>19825872 #
1. tialaramex ◴[] No.19825872[source]
I would like to live in a world where OCSP stapling is widely deployed and we can require OCSP and advise people to set must-staple if possible while everybody who doesn't staple will just have to eat the privacy implications. But this is not (yet and for the foreseeable future) that world.

Apache and nginx both shipped OCSP stapling implementations that are very bad, awful enough that for almost anyone I'd say "No, don't enable that" rather than try to explain how they need to use it and get them to a place where it's useful and safe. Adam Langley wrote years ago about how to do this correctly, and there does seem to be a little bit of movement in the correct direction at Apache, but the situation remains pretty poor.