4 ms·
It's convention. With browsers, you wouldn't want to introduce a recursion point in TLS (we already have certificate chains, and now we'd get OCSP check chains
by marcan_42 6y ago
It's convention. With browsers, you wouldn't want to introduce a recursion point in TLS (we already have certificate chains, and now we'd get OCSP check chains and where does that terminate?). Apple just did what everyone else does for OCSP, in a way which is accepted practice for good reasons.
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.
- topranks 6y agoCorrect. 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.”
- tptacek 6y agoNo browser supports DANE, or has any plan to do so; in fact, Chrome tried supporting DANE, and stopped.