Hacker News

points by commandlinefan 1 day ago | 0 comments

It seems like we've all just... given up on certificate revocation? CRLs and OCSP were designed for exactly this sort of thing, but they both seen to have been abandoned as unworkable with no replacement.

[–] acdha 1 day ago

It’s a hard problem: if you query on use, you not only introduce delay but also leak information about what servers people are connecting to. Dealing with that starts looking a lot more complicated (bloom filters per CA of recently-revoked cert IDs?) needing to be implemented into multiple libraries and the failure mode is an outage unless you fail open.

[–] boston_clone 1 day ago

Same here - I genuinely thought this would have been easily, and almost immediately, remediated vis-a-vis CRLs. I'm not in the vuln management space anymore, but is there some sort of caching system used which would affect software differently than a typical browser?

Editing to add a link to this Apple support article which is unsurprisingly detailed - https://support.apple.com/en-us/149555

[–] zerocrates 1 day ago

As far as I'm aware the typical command-line stuff and most things just using SSL libs or language standard libraries don't do revocation at all by default.

Similar reason (though with the opposite effect) as how a cert can be fine for browsers but fail for curl when they don't send an intermediate: the "vanilla"/library/command-line stuff is just checking for a path to a trusted cert and not doing the CRL or AIA stuff a browser does.

[–] boston_clone 1 day ago

Yes, exactly what the Apple article highlights! Appreciate the extra context.

CLI-based activity references etc/ssl/cert.pem. While they say this will be updated in the future (likely the next dot release), admins can also proactively remove the eMudhra entries.