Hacker News new | past | comments | ask | show | jobs | submit login

Honestly I'm trying to think of a reason you would WANT to disable OCSP, I'm having enough problems thinking of more than 2 developers I know who can actually articulate how it works enough to evaluate this. Not that it's complicated—it's just mostly invisible.

Even when OCSP is a problem, generally you're more worried about issuing a new certificate than an immediate workaround. What are you going to do, ask all your customers to go into keychain access to work around your problem?

This behavior of slowing down appears to be because apple is making HTTPS connections apparently synchronously (probably unnecessarily) and you'd only be potentially harming yourself by disable OCSP.

Though, I am often frustrated FLOSS desktops and Windows don't allow the behavior I want—maybe this is just cultural.

How about it's totally ineffective? OCSP is pointless if you "soft fail" when the OCSP server can't be reached. [1]

This is why Chrome disabled OSCP by default all the way back in 2012-2013 era. Not to mention the performance cost of making all HTTPS connections wait for an OCSP lookup. [2]

[1]: https://www.imperialviolet.org/2012/02/05/crlsets.html

[2]: https://arstechnica.com/information-technology/2012/02/googl...

That's why there's OCSP stapling and OCSP must staple. Ever seen an nginx server fail HTTPS connection exactly once after rotating the certificate? That's nginx lazily fetching the OCSP response from upstream for stapling purposes.

Notarization has a similar "stapling" workflow as well.

Well, security starts from the user. If you're not mindful of what websites you visit, or what files/apps you download and run, there's no OCSP or anything else there to save you.

OCSP enabled or not, you're still one website click away from being pwned to oblivion, giving full control to the hacker – which, of course, is inevitable to an extent, since bugs always find their way into software.

So why not make it easy to disable?

Well, are you going to manually look up certificate revocations yourself? This necessarily requires a network lookup—you can't just glance at the certificate. What's the benefit of disabling this functionality that actively alerts you to revocations?

> Well, security starts from the user. If you're not mindful of what websites you visit, or what files/apps you download and run, there's no OCSP or anything else there to save you.

Sure, but we're discussing good-faith security here. Presumably if people complain about a missing feature they can envision using it. The scenario here is not visiting a shady website and doing something stupid, the scenario here is something like a man-in-the middle attack using a revoked certificate, which would by definition by difficult for the end-user to detect.

> So why not make it easy to disable?

Because then people would disable it for no discernable good effect.

I mean let me be clear, if you're a security researcher you can just modify your own HTTP stack, run a VM, control the hardware, whatever. This isn't a blocker to investigating HTTPS reactions sans OCSP—this is about denying secure connections when they've publicly revoked the cert used to sign the connection. The only reason this is even considered a discrete feature is that most people have never written an OCSP request in order to then trust an HTTPS server—you're just opening yourself up to be misled without even realizing this (and this goes for most of my very network-stack-aware coworkers).

If you're in a browser, you want the browser to be using best practice security, which necessarily includes OCSP. If you know what you're doing this is trivial to bypass.

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