←back to thread

MacOS Catalina: Slow by Design?

(sigpipe.macromates.com)
2031 points jrk | 2 comments | 22 May 20 15:39 UTC | HN request time: 0.001s | source
Show context
usmannk ◴[22 May 20 19:25 UTC] No.23275922[source]▶
It seems like there is a lot of confusion here as to whether this is real or not. I've been able to confirm the behavior in the post by:

- Using a new, random executable. Even echo $rand_int will work. Edit: What I mean here is generate your rand int beforehand and statically include it in your script.

- Using a fresh filename too. Just throw a rand int at the end there. e.g. /tmp/test4329.sh

I MITMd myself while recording the network traffic and, sure enough, there is a request to ocsp.apple.com with a hash in the URL path and a bunch of binary data in the response body. Unsure what it is yet but the URL suggests it is generating a cert for the binary and checking it. See: https://en.wikipedia.org/wiki/Online_Certificate_Status_Prot...

Here's the URL I saw:

http://ocsp.apple.com/ocsp-devid01/ME4wTKADAgEAMEUwQzBBMAkGB...

Edit2: Anyone know what this hash format is? It's not quite base64, nor is it multiple base64 strings separated with '+'s but it seems similar...

Edit3: Here is the exact filename and file I used: https://gist.github.com/UsmannK/abb4b239c98ee45bdfcc5b284bf0...

Edit4 (final one probably...): On subsequent attempts I'm only seeing a request to https://api.apple-cloudkit.com and not the OCSP one anymore. Curiously, there's no headers at all. It is just checking for connectivity.

replies(13): >>23275956 #>>23276180 #>>23277591 #>>23277808 #>>23278027 #>>23278103 #>>23278258 #>>23278367 #>>23278388 #>>23279695 #>>23281103 #>>23284359 #>>23420492 #
kccqzy ◴[22 May 20 19:30 UTC] No.23275956[source]▶
OCSP is Online Certificate Status Protocol, generally used for checking the revocation status of certificates. You used to be able to turn it off in keychain access, but that ability went away in recent macOS releases.
replies(1): >>23276763 #
VonGuard ◴[22 May 20 20:45 UTC] No.23276763[source]▶
Ah, Apple. When you can no longer innovate, just start removing features and call it simplicity...
replies(4): >>23277034 #>>23277355 #>>23277462 #>>23279640 #
monadic2 ◴[22 May 20 21:39 UTC] No.23277355[source]▶
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.

replies(2): >>23277511 #>>23277850 #
1. cliffsteele ◴[22 May 20 22:35 UTC] No.23277850[source]▶
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?

replies(1): >>23278184 #
2. monadic2 ◴[22 May 20 23:16 UTC] No.23278184[source]▶
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.