3 ms·

The loop argument makes no sense at all. HTTP is being used as a transport for a base64-encoded payload, the actual process of veryfing the validity of the deve

The loop argument makes no sense at all. HTTP is being used as a transport for a base64-encoded payload, the actual process of veryfing the validity of the developer certificate is done by the service behind that Apple URL - not by the HTTP stack. There is no justification not to switch to HTTPS here.

samatman 6y ago
Yeah, that confused me as well. 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?
- brabel 6y ago
  The OCSP RFC[1] specifies that if requests are made using HTTP, they MAY be protected via TLS or "some other lower-layer protocol". [1] https://tools.ietf.org/html/rfc6960#appendix-A.1 https://tools.ietf.org/html/rfc6960#appendix-A.1
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 ago
  Correct. 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 ago
    No browser supports DANE, or has any plan to do so; in fact, Chrome tried supporting DANE, and stopped.
topranks 6y ago
Ok say we switch OSCP to HTTPS. 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.
- Matt3o12_ 6y ago
  Well, the problem is that OSCP is leaking which applications you open (and when you open them) which is the big deal IMO. One solution would be that the OSCP is checking the HTTPs certificate in cleartext once upon startup (and maybe once every day or so thereafter), and is using HTTPs for all subsequent application requests. 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.
- mrcybermac 6y ago
  Why can't we use a combo of HTTP and HTTPS?

samatman 6y ago

Yeah, that confused me as well. 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?

brabel 6y ago
The OCSP RFC[1] specifies that if requests are made using HTTP, they MAY be protected via TLS or "some other lower-layer protocol". [1] https://tools.ietf.org/html/rfc6960#appendix-A.1 https://tools.ietf.org/html/rfc6960#appendix-A.1

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 ago
Correct. 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 ago
  No browser supports DANE, or has any plan to do so; in fact, Chrome tried supporting DANE, and stopped.

topranks 6y ago

Ok say we switch OSCP to HTTPS. 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.

Matt3o12_ 6y ago
Well, the problem is that OSCP is leaking which applications you open (and when you open them) which is the big deal IMO. One solution would be that the OSCP is checking the HTTPs certificate in cleartext once upon startup (and maybe once every day or so thereafter), and is using HTTPs for all subsequent application requests. 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.
mrcybermac 6y ago
Why can't we use a combo of HTTP and HTTPS?