7 ms·

Apple: Developer ID Certificate Revocation (OCSP)

82 points by milen 6y ago

X-Istence 6y ago
HP to Apple: "Please revoke this certificate" Apple: "Okay done" Lapcatsoftware: "Apple is to blame for revoking this certificate" How is Apple supposed to know that the certificate has not been compromised? When I ask my CA to revoke a certificate I don't have to explain why to them, they just do it. They are my consequences to bear.
- saagarjha 6y ago
  Why else should Apple even be involved in the revocation process?
  - colejohnson66 6y ago
    Someone has to give you the revocation list, and consumers generally aren’t smart enough to know even what a revocation list is. On Windows, it’s Microsoft. On macOS, it’s Apple.
    - saagarjha 6y ago
      Apple's revocation policy gives you no control over the revocation–you ask them to revoke things for you by contacting them, and then they decide whether this seems like a valid request, then they grant it for you. This is not how revocation usually works, so if so, why is Apple not vetting requests when they are placing themselves into the process?
      - X-Istence 6y ago
        That's the same way a CA works (except with a bit of automation instead of emailing someone). I go to the CA that issued my cert and say "I'd like to revoke this" (whether that is an API call or an email), they then publish the cert into their certificate revocation list. Now, Apple could deny a request, but they are under no obligation to do so, and I would argue that they shouldn't be making those judgement calls. As they did here, they get the email, they then publish the CRL, and wash their hands off it.
        saagarjha 6y ago
        But that is exactly what they claim they are there to do. They should either just accept any request, or do a good job at denying incorrect revocations.
        X-Istence 6y ago
        Where do they claim to do that? Maybe there is no API for it because it happens so rarely that letting the Apple Security team push a few buttons is more cost effective.
- jchw 6y ago
  Your quote of Lapcatsoftware is just wrong. It is not: > Apple is to blame for revoking this certificate. It is: > So blame must be apportioned to both companies. ...because the revocation itself seems to have been an unjustified request. It seems the value-add of Apple having the sole ability to revoke certificates would be that they could avoid something like this. (That said, I do think this is still mostly HP's fault, but the article raises a point that is more valid than implied.)
  - abiogenesis 6y ago
    What should be the proper process then? Should Apple reply to all revocation requests asking for a proof that the certificate has really been compromised? OCSP or CRL revocations are easy to revert, so why risk letting a compromised certificate to be used for an extended amount of time?
    - jchw 6y ago
      Beats me. Apple could just give developers full discretion, which would lower the amount of time it takes to get a really compromised certificate even more. Presumably, there is some good reason to have manual discretion, otherwise, why have it?
    - bentcorner 6y ago
      I agree that HP was careless here but IMO Apple should learn here that developers who ask for a cert revocation may not understand the consequences or the cases where this is necessary. I have no idea what the cert revocation workflow looks like, but providing cases where it should and shouldn't be used would be useful. It's still certainly possible that this falls squarely on HP and there's only so much you can do when someone is determined to blow their foot off.
    - tgsovlerkhgsel 6y ago
      As far as I know, CRL revocations are considered irreversible if done with any reason except certificateHold.
  - X-Istence 6y ago
meibo 6y ago
The check consists of an HTTP GET request (port 80, unencrypted!) to ocsp.apple.com Am I missing something? Is this still the case? Seems like an obvious privacy issue, to be able to identify if an user is launching apps from a certain developer just by doing very basic packet capture.
- jlgaddis 6y ago
  Yes, OCSP is unencrypted (and uses HTTP). OCSP requests only include the certificate's serial number, however, and (AFAIK) Apple does not publish a directory of all issued certificates. WRT the web PKI, though, yes, the serial number can be looked up in CT logs. Although that same "basic packet capture" will give you the hostname of the server -- at least until encrypted SNI is used everywhere. (As for why OCSP is unencrypted, chicken and egg... rsponses are signed, however.)
  - sneak 6y ago
    Apple doesn't need to publish it. All one needs to do is collect a bunch of OSX apps (app store, creative cloud, web downloads of .dmg, whatever) and pull out the certificate serial numbers. This mapping is effectively public data, if you bother to go about collecting it. Then, anyone monitoring your connection knows which apps you launch, when, and where you do it. Additionally, Akamai (and their ISPs) get your complete (IP geolocation) tracklog, and knows when you're at home, when you're traveling, and which apps you use in those places. I wrote about the consequences of this just an hour ago: https://news.ycombinator.com/item?id=25078034 https://news.ycombinator.com/item?id=25078034 Interesting thing is, Apple will deny apps from the App Store that make unencrypted connections (via App Transport Security), but their own, firewall-exempt, vpn-bypassing system processes can do it just fine. :D
    - mleonhard 6y ago
      I want this to be big news. Apple lately pretends that they care about user privacy. They might fix it.
donor20 6y ago
What the heck. You don't have to prove private key compromise for a CA to revoke a cert, you just ask them to revoke it. How in the world is this apple's fault? As long as they authenticate the person requesting the revocation. In most CA's, this can be done by signing the request with the private key to prove control. Now we are told that blame "MUST" be apportioned? "HP and Apple failed in their responsibility" For all we know HP could have found a remote zero day exploit in their drivers, and was going to initiate a replacement effort or something. The author also complains no CRL is available, but that's a good thing in these cases, if there is a mistake certificate status can be updated. So again, apple has an approach here that means it's not too hard to get folks printing again. The author makes a case that a publisher can only revoke in the case of malware and key compromise. I can think of PLENTY of situations where revocation might make sense (and publisher may be still sued I'm sure) outside of that, for small teams and even for big teams.
heavensgateboy 6y ago
This entire thing is likely related to Apple’s engineered obsolescence cycle. They have already been busted intentionally causing issues on their platforms prior to the release of new products in order to drive sales. It’s a grey area legally and difficult to prove, but it’s essentially a form of racketeering.
- purplecats 6y ago
  It seems a lot of your comments garner downvotes on this site. Your comments are sound, or at least very reasonable, and thus my opinion of this site and the community has faltered significantly.
SAI_Peregrinus 6y ago
A certificate revocation request signed by the private key is proof of private key compromise. Anyone issuing such a revocation due to knowledge of compromise of the key is notifying the issuing authority of the compromise. If a key is used for a purpose not listed as allowed in the certificate, it's compromised, even if the entity that misused the key is the original holder. Anyone issuing such a revocation without authorization has the private key, and is using it for something they're not authorized to use it for. It's compromised by definition. There's never a reason not to revoke a certificate when a valid revocation request is received. The key has been compromised, either by leaking or by misuse.
- _qulr 6y ago
  > A certificate revocation request signed by the private key is proof of private key compromise. There's no such thing in this case. In the blog post, I quoted from Apple's Certification Practice Statement: "The Subscriber may initiate a revocation request by sending an email to productsecurity@apple.com. The request for revocation will then be evaluated by Apple." Everyone wants to make an analogy between Developer ID code signing certificates and web server certificates, but the usage of the two kinds of certs is completely different.
tgsovlerkhgsel 6y ago
> The check consists of an HTTP GET request (port 80, unencrypted!) to ocsp.apple.com with a path that is both Base64 encoded and URL encoded. Interesting. This means OSX leaks which apps you run unencrypted on the network.
- tatersolid 6y ago
  windows and web browsers do this as well via OSCP. Linux distros also do this via package manager traffic and update checks. Apt/rpm traffic is unencrypted, relying on a separate payload signature scheme for authenticity (same as OSCP).

82 points by milen 6y ago

HP to Apple: "Please revoke this certificate" Apple: "Okay done" Lapcatsoftware: "Apple is to blame for revoking this certificate" How is Apple supposed to know that the certificate has not been compromised? When I ask my CA to revoke a certificate I don't have to explain why to them, they just do it. They are my consequences to bear.

saagarjha 6y ago
Why else should Apple even be involved in the revocation process?
- colejohnson66 6y ago
  Someone has to give you the revocation list, and consumers generally aren’t smart enough to know even what a revocation list is. On Windows, it’s Microsoft. On macOS, it’s Apple.
  - saagarjha 6y ago
    Apple's revocation policy gives you no control over the revocation–you ask them to revoke things for you by contacting them, and then they decide whether this seems like a valid request, then they grant it for you. This is not how revocation usually works, so if so, why is Apple not vetting requests when they are placing themselves into the process?
    - X-Istence 6y ago
      That's the same way a CA works (except with a bit of automation instead of emailing someone). I go to the CA that issued my cert and say "I'd like to revoke this" (whether that is an API call or an email), they then publish the cert into their certificate revocation list. Now, Apple could deny a request, but they are under no obligation to do so, and I would argue that they shouldn't be making those judgement calls. As they did here, they get the email, they then publish the CRL, and wash their hands off it.
      - saagarjha 6y ago
        But that is exactly what they claim they are there to do. They should either just accept any request, or do a good job at denying incorrect revocations.
        X-Istence 6y ago
        Where do they claim to do that? Maybe there is no API for it because it happens so rarely that letting the Apple Security team push a few buttons is more cost effective.
jchw 6y ago
Your quote of Lapcatsoftware is just wrong. It is not: > Apple is to blame for revoking this certificate. It is: > So blame must be apportioned to both companies. ...because the revocation itself seems to have been an unjustified request. It seems the value-add of Apple having the sole ability to revoke certificates would be that they could avoid something like this. (That said, I do think this is still mostly HP's fault, but the article raises a point that is more valid than implied.)
- abiogenesis 6y ago
  What should be the proper process then? Should Apple reply to all revocation requests asking for a proof that the certificate has really been compromised? OCSP or CRL revocations are easy to revert, so why risk letting a compromised certificate to be used for an extended amount of time?
  - jchw 6y ago
    Beats me. Apple could just give developers full discretion, which would lower the amount of time it takes to get a really compromised certificate even more. Presumably, there is some good reason to have manual discretion, otherwise, why have it?
  - bentcorner 6y ago
    I agree that HP was careless here but IMO Apple should learn here that developers who ask for a cert revocation may not understand the consequences or the cases where this is necessary. I have no idea what the cert revocation workflow looks like, but providing cases where it should and shouldn't be used would be useful. It's still certainly possible that this falls squarely on HP and there's only so much you can do when someone is determined to blow their foot off.
  - tgsovlerkhgsel 6y ago
    As far as I know, CRL revocations are considered irreversible if done with any reason except certificateHold.
- X-Istence 6y ago

meibo 6y ago

The check consists of an HTTP GET request (port 80, unencrypted!) to ocsp.apple.com Am I missing something? Is this still the case? Seems like an obvious privacy issue, to be able to identify if an user is launching apps from a certain developer just by doing very basic packet capture.

jlgaddis 6y ago
Yes, OCSP is unencrypted (and uses HTTP). OCSP requests only include the certificate's serial number, however, and (AFAIK) Apple does not publish a directory of all issued certificates. WRT the web PKI, though, yes, the serial number can be looked up in CT logs. Although that same "basic packet capture" will give you the hostname of the server -- at least until encrypted SNI is used everywhere. (As for why OCSP is unencrypted, chicken and egg... rsponses are signed, however.)
- sneak 6y ago
  Apple doesn't need to publish it. All one needs to do is collect a bunch of OSX apps (app store, creative cloud, web downloads of .dmg, whatever) and pull out the certificate serial numbers. This mapping is effectively public data, if you bother to go about collecting it. Then, anyone monitoring your connection knows which apps you launch, when, and where you do it. Additionally, Akamai (and their ISPs) get your complete (IP geolocation) tracklog, and knows when you're at home, when you're traveling, and which apps you use in those places. I wrote about the consequences of this just an hour ago: https://news.ycombinator.com/item?id=25078034 https://news.ycombinator.com/item?id=25078034 Interesting thing is, Apple will deny apps from the App Store that make unencrypted connections (via App Transport Security), but their own, firewall-exempt, vpn-bypassing system processes can do it just fine. :D
  - mleonhard 6y ago
    I want this to be big news. Apple lately pretends that they care about user privacy. They might fix it.

donor20 6y ago

What the heck. You don't have to prove private key compromise for a CA to revoke a cert, you just ask them to revoke it. How in the world is this apple's fault? As long as they authenticate the person requesting the revocation. In most CA's, this can be done by signing the request with the private key to prove control. Now we are told that blame "MUST" be apportioned? "HP and Apple failed in their responsibility" For all we know HP could have found a remote zero day exploit in their drivers, and was going to initiate a replacement effort or something. The author also complains no CRL is available, but that's a good thing in these cases, if there is a mistake certificate status can be updated. So again, apple has an approach here that means it's not too hard to get folks printing again. The author makes a case that a publisher can only revoke in the case of malware and key compromise. I can think of PLENTY of situations where revocation might make sense (and publisher may be still sued I'm sure) outside of that, for small teams and even for big teams.

heavensgateboy 6y ago

This entire thing is likely related to Apple’s engineered obsolescence cycle. They have already been busted intentionally causing issues on their platforms prior to the release of new products in order to drive sales. It’s a grey area legally and difficult to prove, but it’s essentially a form of racketeering.

purplecats 6y ago
It seems a lot of your comments garner downvotes on this site. Your comments are sound, or at least very reasonable, and thus my opinion of this site and the community has faltered significantly.

SAI_Peregrinus 6y ago

A certificate revocation request signed by the private key is proof of private key compromise. Anyone issuing such a revocation due to knowledge of compromise of the key is notifying the issuing authority of the compromise. If a key is used for a purpose not listed as allowed in the certificate, it's compromised, even if the entity that misused the key is the original holder. Anyone issuing such a revocation without authorization has the private key, and is using it for something they're not authorized to use it for. It's compromised by definition. There's never a reason not to revoke a certificate when a valid revocation request is received. The key has been compromised, either by leaking or by misuse.

_qulr 6y ago
> A certificate revocation request signed by the private key is proof of private key compromise. There's no such thing in this case. In the blog post, I quoted from Apple's Certification Practice Statement: "The Subscriber may initiate a revocation request by sending an email to productsecurity@apple.com. The request for revocation will then be evaluated by Apple." Everyone wants to make an analogy between Developer ID code signing certificates and web server certificates, but the usage of the two kinds of certs is completely different.

tgsovlerkhgsel 6y ago

> The check consists of an HTTP GET request (port 80, unencrypted!) to ocsp.apple.com with a path that is both Base64 encoded and URL encoded. Interesting. This means OSX leaks which apps you run unencrypted on the network.

tatersolid 6y ago
windows and web browsers do this as well via OSCP. Linux distros also do this via package manager traffic and update checks. Apt/rpm traffic is unencrypted, relying on a separate payload signature scheme for authenticity (same as OSCP).