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.
Apple: Developer ID Certificate Revocation (OCSP)
21–30 of 35 posts
Re: Apple: Developer ID Certificate Revocation (OCSP)
#22Earlier quoted context omitted.
> Replace Apple with any CA on the world wide web This is what everyone misunderstands. The Developer ID code signing program is not analogous to web certs. The usage of these certs is entirely different. Apps installed on a user's Mac are expected to run indefinitely, essentially forever. Developer ID signing certs do expire, but expiration only affects their ability to sign new app versions, it doesn't prevent old…
>This is what everyone misunderstands. The Developer ID code signing program is not analogous to web certs. The usage of these certs is entirely different. If a web cert gets revoked a browser won't accept it when making a connection to a domain/server anymore even if they previously did (unless you make it). If an app signing cert gets revoked the OS won't run a binary signed with it anymore even if it previously di…
> If a web cert gets revoked a browser won't accept it when making a connection to a domain/server anymore even if they previously did
The difference is that you can just get a new web cert, install it on the server, and you're good to go for https. On the other hand, getting a new Developer ID cert doesn't help at all to make the app start running again. You can sign new versions of the app with the new cert, but the installed versions of the app signed with the revoked cert are still dead as a doornail, which is no good at all for your existing user base.
> The main and basically almost only reason where I see developer side revocation be used is if their keys or account have been (possibly) compromised and therefore there's a chance of it being used for malware.
It's not clear that this ever happens. I discussed the case of Panic in the blog post. Their private key was possibly compromised, but Apple did not revoke their cert! The old cert is still valid, and so are the old versions of their apps. Apple apparently has a more limited way of disabling apps, based on the secure timestamp of the code signature.
Re: Apple: Developer ID Certificate Revocation (OCSP)
#23A 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.
Re: Apple: Developer ID Certificate Revocation (OCSP)
#24The 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.
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.)
Re: Apple: Developer ID Certificate Revocation (OCSP)
#25A 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…
> 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.
Re: Apple: Developer ID Certificate Revocation (OCSP)
#26The 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.
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 un…
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
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
Re: Apple: Developer ID Certificate Revocation (OCSP)
#27Earlier quoted context omitted.
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 un…
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 comp…
I want this to be big news. Apple lately pretends that they care about user privacy. They might fix it.
Re: Apple: Developer ID Certificate Revocation (OCSP)
#28Earlier quoted context omitted.
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 f…
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?
As far as I know, CRL revocations are considered irreversible if done with any reason except certificateHold.
Re: Apple: Developer ID Certificate Revocation (OCSP)
#29> 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.
Re: Apple: Developer ID Certificate Revocation (OCSP)
#30Earlier quoted context omitted.
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 comp…
I want this to be big news. Apple lately pretends that they care about user privacy. They might fix it.
Sorry, what, exactly, should be fixed?
If you're referring to OCSP requests / responses being unencrypted, I would be interested in hearing what your solution to this problem is.
Also, I would recommend that you do not perform any packet captures (as mentioned earlier) to observe your OCSP traffic. You're gonna have a heart attack when you realize that this isn't just an Apple thing and that nobody encrypts OCSP.
Once you understand why, I'd be interested in hearing your new, revised solution.
Finally, it's not quite as bad as sneak makes it out to be. OCSP responses are cached so, as mentioned in TFA (so certificate status is not being checked every time you launch every app), although I'm not sure what the validity interval of OCSP responses from ocsp.apple.com is (and don't have anything running macOS to check). Additionally, I don't see anyone but Apple announcing any part of the 17/8 network (regardless of ocsp.apple.com. being CNAME'd to Akamai).