5 ms·

Isn’t OCSP an open standard for handling certificate revocations? The standard specifies plaintext, because the standard can’t assume that the client has a way

Isn’t OCSP an open standard for handling certificate revocations? The standard specifies plaintext, because the standard can’t assume that the client has a way to form an encrypted connection to the revocation list.

remram 6y ago
Wouldn't an anonymity scheme such as [1] work in this context? Send only part of the hash of the app's certificate, and have the server send you all possible revoked certificates? [1]: https://blog.cloudflare.com/validating-leaked-passwords-with-k-anonymity/ https://blog.cloudflare.com/validating-leaked-passwords-with...
- est31 6y ago
  As the set of certificates is bounded and known by apple, they can also adopt crlite and just push all CRLs they have to all users, using CRLite. https://github.com/mozilla/crlite https://github.com/mozilla/crlite
  - remram 6y ago
    I assumed there were too many revoked certificates for something like this to be viable, but I'm not surprised it is. You probably can't update the whole list that often though, compared to Apple's current OCSP revalidate time of 5 min. [edit: seems "delta patches" are supported by crlite so maybe that can work too]
    - est31 6y ago
      > I assumed there were too many revoked certificates for something like this to be viable, but I'm not surprised it is. Given that Apple currently doesn't even encrypt the requests during transit, I think they just didn't pay much attention to the problem, which I think the main reason is why they haven't adopted it yet. As for the number of revoked certificates, I'm not sure it's larger than the number of revoked TLS certificates, given that there are way more websites out there than there are registered apple developers.
- mnahkies 6y ago
  This is pretty much how chrome's safe browsing feature works for screening URLs without leaking the full details. There is no valid reason that the full information needs to be sent to the server to implement this kind of protection IMO
marcus_holmes 6y ago
Why is Apple limited bu Open Standards? It's not like any other servers are going to be receiving these messages.
sneak 6y ago
The standard does not specify plaintext. It says the client may use encryption. Even doing unauthenticated TLS is better than what they do now, because the current situation allows for full passive monitoring.
- angry_octet 6y ago
  The problem with 'may' is that a network intermediary might block TLS connections to ocsp.apple.com knowing it would fall back to plaintext. Apple could encrypt the payload though, using the Apple public key, which would solve the snooping by intermediaries problem.
  - sneak 6y ago
    A network intermediary blocking or altering the TLS is an active attack. Plain HTTP is also vulnerable to that, so unauthenticated TLS is no worse than the current situation. TLS encrypts the payload just fine if you want that. That’s what TLS is for. PS: You don’t encrypt something to someone else using your own public key.
    - angry_octet 6y ago
      I'm talking about when they block just the ocsp host TLS port. Heaps of places whitelist https for particular sites, and inspect the content to prevent TLS. Appliances that block TLS via packet inspection are dime a dozen. But the query/response fields can be an opaque encrypted blob and it would get through. Every Apple device obviously has the Apple pub key, and hence they can send encrypted messages back to Apple without needing any further PKI.

remram 6y ago

Wouldn't an anonymity scheme such as [1] work in this context? Send only part of the hash of the app's certificate, and have the server send you all possible revoked certificates? [1]: https://blog.cloudflare.com/validating-leaked-passwords-with-k-anonymity/ https://blog.cloudflare.com/validating-leaked-passwords-with...

est31 6y ago
As the set of certificates is bounded and known by apple, they can also adopt crlite and just push all CRLs they have to all users, using CRLite. https://github.com/mozilla/crlite https://github.com/mozilla/crlite
- remram 6y ago
  I assumed there were too many revoked certificates for something like this to be viable, but I'm not surprised it is. You probably can't update the whole list that often though, compared to Apple's current OCSP revalidate time of 5 min. [edit: seems "delta patches" are supported by crlite so maybe that can work too]
  - est31 6y ago
    > I assumed there were too many revoked certificates for something like this to be viable, but I'm not surprised it is. Given that Apple currently doesn't even encrypt the requests during transit, I think they just didn't pay much attention to the problem, which I think the main reason is why they haven't adopted it yet. As for the number of revoked certificates, I'm not sure it's larger than the number of revoked TLS certificates, given that there are way more websites out there than there are registered apple developers.
mnahkies 6y ago
This is pretty much how chrome's safe browsing feature works for screening URLs without leaking the full details. There is no valid reason that the full information needs to be sent to the server to implement this kind of protection IMO

marcus_holmes 6y ago

Why is Apple limited bu Open Standards? It's not like any other servers are going to be receiving these messages.

sneak 6y ago

The standard does not specify plaintext. It says the client may use encryption. Even doing unauthenticated TLS is better than what they do now, because the current situation allows for full passive monitoring.

angry_octet 6y ago
The problem with 'may' is that a network intermediary might block TLS connections to ocsp.apple.com knowing it would fall back to plaintext. Apple could encrypt the payload though, using the Apple public key, which would solve the snooping by intermediaries problem.
- sneak 6y ago
  A network intermediary blocking or altering the TLS is an active attack. Plain HTTP is also vulnerable to that, so unauthenticated TLS is no worse than the current situation. TLS encrypts the payload just fine if you want that. That’s what TLS is for. PS: You don’t encrypt something to someone else using your own public key.
  - angry_octet 6y ago
    I'm talking about when they block just the ocsp host TLS port. Heaps of places whitelist https for particular sites, and inspect the content to prevent TLS. Appliances that block TLS via packet inspection are dime a dozen. But the query/response fields can be an opaque encrypted blob and it would get through. Every Apple device obviously has the Apple pub key, and hence they can send encrypted messages back to Apple without needing any further PKI.