There is no justification not to switch to HTTPS here.
Now in this specific instance, OCSP is being used in quite a different use case. For one, the plaintext issue is not a problem when browsing, as attackers can see what sites/certs you're accessing in the clear anyway (certificates are plaintext in TLS sessions), while app launch is an otherwise offline activity. So in this instance it makes sense for Apple to switch to HTTPS (and if they have OCSP on the server cert for that, that should go via HTTP to avoid loops or further issues).
But what Apple did here is just standard practice, it's just that there happen to be good reasons to diverge from the standard here.
Want to point out that certs are encrypted with TLS1.3, and DNSSEC+DoT/DoH makes ESNI/ECH possible by putting keys in the DNS.
Ultimately maybe OSCP could do something similar, or fall back to DANE or some alternate validation method that wouldn’t cause a “loop.”
How to we know the certificate presented by the OSCP server has not been revoked? We can’t ask the OSCP server cos that’s what we’re trying to handshake with!
The loop is very real and non trivial to solve. I’d expect something similar to what ESNI/ECH does leveraging DNSSEC + DoH may be possible NOW, but that’s a recent development.
I don't really see a problem here how that could cause a loop. This way, an attacker can only see:
- When you boot your Mac because it verifies the HTTPs certificate once.
- When the OSCP daemon makes a clear text request to check that the HTTPs cert is still ok
- That you have just opened an application (but not which application)
IMO that still leaks an unacceptable amount of meta data but it is miles better then using cleartext. Maybe a bloom filter here would be a much better solution + make the daemon regularly fetch bad signature that are not added the the filter yet instead of pulling. Sure the filter may hit false positives sometimes but in that case, the OSCP server could be checked and apple could see if a certificate has a high rate of false positives and adjust the bloom filter accordingly.
Even if there was some wrinkle about the loop argument that I didn't understand, and HTTPS is out: Apple could encrypt the base64 payload, and the sniffable info is reduced to which computer is phoning home, which is something that someone with the ability to middle comms probably knows already.
"roll your own encryption and send it over HTTP" is a bad idea in general but... this is Apple, they can and do implement encryption. Why not here?