* There is no information on how often the validation happens. All this investigation concludes is that it doesn't happen when closing and immediately re-opening an app. Is it every week? Every reboot? Every hour? If it's less, that's essentially the same as doing it on every launch.
* There is no justification for sending this information in cleartext. I don't follow the "browsers and loops" argument. This is a system-service that only has to trust a special Apple certificate, which can be distributed via other side-channels.
* Many developers only publish a single app or a certain type of app. So it still is a significant information leak. It's really not much different from sending a app-specific hash. Think: remote therapy/healthcare apps, pornographic games, or Tor - which alone could get you into big trouble or on a watchlist in certain regions.
I assume they will push a fix with better timeouts and availability detection.
But Apple simply has to find a more privacy-aware system designs for this problem which does not leak this kind of data without an opt-in and also does not impact application startup times. (revocation lists?)
I imagine this data might just be too attractive not to have. Such a "lazy" design is hard to imagine coming out of Apple otherwise.
1) Even plain access logs — basically what a HTTP request, or a TCP connection can tell you — is a lot. Gather those for a couple of days, and you have a good map of the user. More so if you have an ID of machine and the actual executable hash.
2) "But we are the good guys" is a non-defense. Good guys can turn bad, they can be coerced by the bad guys, and
3) since the requests fly out in plain text, there is an unknown number of questionably-aligned guys in between capable of sniff your data. You only need one bad enough guy to get into serious trouble if that's what they want.
This is not alarmist. It's just common sense. The same common sense that you use to avoid certain neighborhoods at certain times of night.
At that point, what’s to prevent you from providing unacceptably slow service for the certs of those apps you don’t like and soft-locking the user out of particular apps on their own device?
Also, this is what every bad guy believed him or herself to be throughout the history of humanity.
That’s true, but not very useful, since if Apple turns bad or is coerced by the bad guys, they could just issue an OS update that begins doing new bad things anyway.
I wrote a blog post about this. My analysis indicates that Developer ID OCSP responses were previously cached for 5 minutes, but Apple changed it to half a day after Thursday's outage, probably to reduce traffic:
Exactly the apologetic that you are talking about. Everyone has a different security update cadence (e.g. patch Tuesday for Microsoft), but each application launch is not a reasonable one. Given Apple's recent propensity for banning developers who stand against them (whether you agree with those developers or not), this is aimed squarely at dissent.
It’s not each application launch. It’s from time to time. It’s for each application as it might be detected to have malware in the future. Also if the app isn’t signed there is no check.
There is no justification not to switch to HTTPS here.
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.
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.
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?
Even doing unauthenticated TLS is better than what they do now, because the current situation allows for full passive monitoring.
[1]: https://blog.cloudflare.com/validating-leaked-passwords-with...
That's my biggest issue personally. There's a bit of information leak, but most wouldn't care and would just do the standard and be done with it. Firefox still uses OCSP in some case...
My issue is that a company like Apple, which currently market itself as a company that care about privacy of their user, would have let this comes out of that same process that's supposed to care... and still hasn't said that was a mistake out of their process and that they are correcting it.
They could easily use k-anonymity like HaveIBeenPwned, or even as push, which would means no cache, which is even better for their argument of security.
There's nothing alarmist here, it's all alright, it would just means that this is the same false advertising that so many companies do, but still, is important to be aware of.
Call home features can be spoofed by a poisoning type of attack upstream in various forms.
This is not bullet proof and a cop-out with a poor solution for security.
You know who has effective call home features? Vendors that sell to major enterprises. It is a natural progression and a particularly nasty environment to live within.
If they are legitimately trying to protect the brand through force or merely forcefully controlling the app ecosystem... it's an abusive relationship to be in.
The fact this is not configurable without dead lettering the route is all they need to do to show tethering is something they consider as a viable security measure.
I'll pass.
The idea that you need apple to certify the developer over the software you run on your phone is nonsense though. You don't do that on your computer, so why do you need to be nannied on your phone?
Potentially it could now be tackled with DNSSEC + DoH similar to the records ESNI/ECH puts in the DNS to encrypt initial HTTPS client hellos.
But the loop issue is quite real. How can you validate the certificate the OSCP server gives you has not been revoked, using OSCP???
I'm not surprised. Apple fanatics routinely deny evidence to support their sorta-religion.
As do anti-Apple fanatics. That’s what being a “fanatic” means. You can say the same about gun fanatics, or meat fanatics, or vegetarian fanatics, or Android fanatics. It’s staggering how often people who are anti something fail to perceive the irony in behaving exactly in the manner they are decrying. Someone having a contrary opinion doesn’t make them a fanatic.
To log in to my banking account, I need the correct password. No problem, I keep it in a password manager. To open the password manager, I need the correct password. No problem, I keep it in a password manager. To open the password manager, I need the correct password. No problem, I keep it in a password manager. To open the password manager, I need the correct password. No problem, I keep it in a password manager. And so on.
Imagine that, but for “verifying the HTTPS connection”.
Technically what I’m describing is that you can vary the behaviour of OCSP lookups such that if you’re already looking up an OCSP certificate to establish an SSL connection to an OCSP server, downgrade and check over HTTP only when trying to connect to the OCSP server itself. Yes, it would mean one more TLS connection to a random server. Yes, it would mean an extra OCSP lookup. But just one, and just for the OCSP server itself. Which means privacy is preserved in regards to which developer certificate you’re checking. It would be only checking Apple’s OCSP server certificate in the clear, which it could equally cache easily.
You can DH with an untrusted cert. It might be interceptable.
HTTP is always interceptable.
But there should be zero reason not to set this connection up with a full proper cert. HTTP is just mega sloppy.
As others mentioned, you can bootstrap TLS by first checking OCSP (in the open) on your cert auth service, then use that opaque, freshly-checked connection to check the rest.
Is it not common knowledge how telemetry works for the operating systems? They generally batch up a bunch of logs like this, encrypt them, compress them, and then send them to the mothership (hopefully when you're on WiFi).
And no, it's not widely known or documented - there is no good description of what telemetry exists or contains on iOS that I know of.
This is bad for users that download apps to solve problems, or to get work done, because then they can't those apps without having an expert tell them what the magic ritual to run un-Notarized apps is. If they don't have an expert around to show them how to perform the magic ritual, then they just think the apps are broken.
They just keep making stuff not private so you have to choose between security versus privacy.
A well thought system would be able to provide both.
Phoned signing verification is another thing that is a precursor to distribution to Apple-only distribution.
Yeah, what's up with that, having to buy a Mac just to run XCode! And having to register as a developer to get a certificate.
Apple should bring back Lisas and the UCSD Pascal/Clascal for Mac development like it was in the 1980s. And they should also bring back 4-letter developer signatures. ;-)
Yes, and no. If you're using software that the state deems to be subversive or "dangerous", a developer certificate would make the nature of the software you are running pretty clear. They don't have to know exactly which program you're running, but just enough information to put you on a list.
> You shouldn’t probably block ocsp.apple.com with Little Snitch or in your hosts file.
I never asked them to do that in the first place, so I'll be blocking it from now on.
Apple's working on making sure you can't block it. They already keep you from blocking their own traffic with Little Snitch and similar tools: https://news.ycombinator.com/item?id=24838816
sudo defaults write /Library/Preferences/com.apple.security.revocation.plist OCSPStyle None
sudo defaults write com.apple.security.revocation.plist OCSPStyle NoneI mean I guess I already know the answer, "marketing". "Look, macOS doesn't require antivirus!"
Personally I don't want Apple verifying or revoking anything. I bought the computer, it's mine. You don't get to tell me what I can run, period. Inform me, sure, give me links to go learn why you don't want me to run something, sure. Don't prevent me from choosing to do with my machine what I want.
Enumerating “all possible badness” is basically impossible, which is why AV software really doesn’t work. Every ransomware attack you read about in the news bypassed up-to-date AV software.
Enumerating “known-good” entities is actually a tractable problem... this is what vendor-signing does. Even Google and Microsoft understand this and have had code-signing infrastructure in place for decades.
Other than Internet Explorer (and maybe Edge? I honestly have no idea) browsers don't do OCSP. This is because it's a huge privacy problem (as we saw here for Apple) and because the OCSP servers have too often been unreliable.
Firefox has OCSP Must Staple, but in that scenario the remote web server is responsible for periodically ensuring it has a sufficiently up-to-date OCSP response about its own certificate which it then "staples" to the certificate to prove its identity. So if the OCSP server fails for an hour a good quality stapling implementation just keeps using older responses until it comes back. Also it's optional, most people haven't chosen to set Must Staple anyway.
Everybody else has various CRL-based strategies, so your browser learns about certain important revocations, eventually, but it doesn't pro-actively check for them on every connection and thus destroy your privacy.
OCSP is a good thing, and the web - and your signed applications - are better off with it.
Active OCSP is far from being considered a good thing universally.
Spoiler alert, you've probably already used OCSP on the web.
It's worth noting a couple differences between HTTPS OCSP and Developer ID OCSP. First, with Developer ID, the only DNS request is for ocsp.apple.com, so the DNS request by itself doesn't expose any information about the Mac app being launched, unlike with HTTPS.
Second, the caching of Developer ID OCSP responses tends to be much much shorter than for HTTPS. Prior to Thursday's outage, the standard cache length for Developer ID OCSP responses seemed to be 5 minutes. (Apple seems to have raised it to 12 hours now.) In contrast, I just checked the latest response in my OCSP cache, which was for http://ocsp.digicert.com, and its validity is 7 days. So the rate at which Developer ID OCSP requests are made seems to be much higher than for HTTPS, and thus there's greater chance of exposure.
That’s why CT came around.
Some background for those unfamiliar.
Wow, that is bad from a privacy perspective!
Since certificate revocation is rare, it makes more sense to simply periodically update a list of revoked certificates instead of repeatedly checking each certificate. That would solve the privacy issue while still allowing certificates to be revoked.
OCSP seems like a bad idea for web browsing for similar reasons.
If there's a hit, a subsequent request can be sent to Apple to verify the same - reducing the impact.
According to Wikipedia "[OCSP stapling] allows the presenter of a certificate to bear the resource cost involved in providing Online Certificate Status Protocol (OCSP) responses by appending ("stapling") a time-stamped OCSP response signed by the CA to the initial TLS handshake, eliminating the need for clients to contact the CA, with the aim of improving both security and performance."
I'm not aware how widely deployed OCSP stapling is in reality. I looked at my Firefox settings which seemed to be the default for OCSP and it looked like this:
security.OCSP.enabled 1
security.OCSP.require false
security.OCSP.timeoutMilliseconds.hard 10000
security.OCSP.timeoutMilliseconds.soft 2000
security.ssl.enable_ocsp_must_staple true
security.ssl.enable_ocsp_stapling true
I also don't know what other TLS implementations (like OpenSSL) do and how users of such libraries usually configure them.
Addendum: Oh and of course, OCSP stapling is useless when you weren't about to open a TLS connection (like in this case when checking software signing certificates). I'm also curious if and how this works for other applications of X.509 certificates such as mutual TLS authentication.
To me, it sounds like they decided to take the quick-and-easy path of reusing an existing protocol for the use case of stopping malware, but it doesn't really fit. The latency, privacy, and availability guarantees of OCSP just don't match with the requirements for "run a local application".
Stapling and crl-shipped-with-browser still works.
If that's happening, they need to put more work up front into certifying them in the first place.
It’s a good thing to do regardless. I also know way more than I want to about Windows, too, and could make do if given only that for a workweek.
Learn languages, learn OSes, learn architectures. Get more computers. :)
I made the switch and I'm not looking back.
Replace "Apple" with "Google", "Facebook", "Verizon". Re-read the article. If it sounds horrifying, then it's also horrifying if Apple does it. There's no such thing as "trust" into a single corporation - especially the one which just argued that you not paying 30% to them is "theft".
Applying this test helps weed out the marketing bias these corpos constantly try to push at you.
Relatedly, does anyone know if Big Sur allows one to use a custom DNS server on the device level with those privileged destinations? (He says, mulling the complexities of getting a pi-hole working with his mesh system.)
I went from blocking about 45% of my entire network's traffic at the DNS level two years ago, to only blocking 10% of the traffic today.
If they use public DoH servers you could just block those at the network level. Andv if they're running their own DoH service on a fixed IP, they could simply run the app itself over that IP and avoid the whole DNS lookup altogether.
In the example from the article: if Mozilla's certificate is sent, then it's very likely that the app that has been opened is Firefox, as the a priori likelihood of using Firefox is way higher than eg using Thunderbird.
If the developer is Telegram LLC, then ... and so on.
Uninformed advice - apple prevents little snitch from blocking this traffic in big sur.
>If you use macOS Big Sur, blocking OCSP might not be as trivial.
> Uninformed advice - apple prevents little snitch from blocking this traffic in big sur.
You can prevent Apple from preventing Little Snitch from blocking that traffic: https://tinyapps.org/blog/202010210700_whose_computer_is_it....
It wasn’t a misunderstanding, it was a simplification so that people could understand the issue without me explaining OCSP and app signing and x509 and the PKI. Dozens of people wrote me to thank me for explaining it in a way that they could understand.
It is indeed a hash, and it does indeed uniquely identify most apps, and it is indeed sent in plaintext, when you launch the app (and is cached for a half day IIRC). I very deliberately didn’t claim it is a hash of the content of the app file.
It also doesn’t send a unique identifier, but I would be willing to wager that the set of apps that you launch in 48h is probably enough to uniquely identify your machine in the vast majority of cases.
This would explain why some games take minutes to launch the first time to run them. I've experienced this many times with Steam. You install a game, you launch it, and nothing happens for up to several minutes, and then the game runs. No delays after in launching after that.
You know, before declaring the end of the world, is there any information from the source (Apple)? Discussions here seem to have had several thousand comments without obtaining this basic info. It would be good to know, I would think?
* Your Mac periodically sends plain text information about the developer of all apps you open, which in most cases makes it trivial for anyone able to listen to your traffic to figure out what apps you open. Better not use a Mac if you're a journalist working out of an oppressive country.
* Because of this Macs can be sluggish opening random applications.
* A Mac is not a general purpose computing device anymore. It's a device meant for running Apple sanctioned applications, much like a smartphone. Which may be fine, depends on the use case.
Yeah... No Mac for me anytime soon then.
And just by looking ip address, and app usage and other data they receive they can connect the data and identify its me. And what security has apple provided till now?
"You shouldn’t probably block ocsp.apple.com with Little Snitch or in your hosts file."
That's far better than freezing computer which doesn't work, doesn't run any apps. If I don't need apple mercy and protection please don't force me.
Already installed Linux and its a start.
This is the reason people laugh at this website.
I wonder how big a local revocation list would be. I would support a on-by-default local check.
http://ocsp.apple.com/ocsp-devid01 is Developer ID, but http://ocsp.apple.com/ocsp03-apevsrsa2g101 is something else, which if blocked can prevent the Mac App Store from loading.
Then unencrypted requests are also a Bad Thing, because anyone has access to the same info - it may require a lot of work to get general knowledge of what apps someone is using, but if you were looking for a specific one then I don't see any real difficulty identifying that.
e.g. if I wanted to know if someone was using signal I just look for the signal cert being queried. That's a much easier problem, and can be dangerous to the end user.
Question, is there a good justification to use not use hierachical certificates like web browsers or other OSes ?
Apple does not prioritize privacy. Apple does not prioritize availability.
I write a lot of Go on my Mac at home. The first run is _always_ slow, but I've never measured it or bothered to find out why. This is a real "lightbulb moment" for me.
I just built a Go executable and timed it: 0.194 for the first, and ~0.018 for subsequent. I haven't signed code on Mac platforms before, so I figured I'd give it a go using the Apple code signing guide [0]. So, I created a self-signed certificate using Keychain, changed and built a Go project, signed the executable [1], and ran it: ~0.400 for the first run, and ~0.018 for subsequent. It... doubled? Will this happen on every first run still? Is there a way to exclude executables?
[0] https://developer.apple.com/library/archive/documentation/Se...
[1] codesign -s <cert_id> <path>
Periodically there would be an issue downloading the updates. Would result in similar problems.
Managing size of updates was a big issue. Just checking against an online server is certainly a more up to date approach
Why not take a more privacy-centric approach? Antivirus companies have been working with “virus definitions” for ages. Ad blockers use the same model, but for locally stored blacklists. Why can Apple not regularly download a list of revoked certificates and maintain it locally?
"You should be aware that macOS might transmit some opaque information..."
Why don't the author post the OCSP request of Thunderbird too? And how about another request for Firefox so we can compare the data? This article really doesn't clear anything up for me...
edit: on 2nd thought just a list of hashed cert ids could suffice because it is hard to imagine there ever being thousands of revocations.
That way the provider would have no knowledge of which certs are being verified.
Also i don't get the argument for using HTTP. Aren't these two separate systems?
How does one go about setting up (easy) server of some sort to see what servers are being connected say when investigating a different area?
They backpedaled a little bit when you were forced to log in through a Microsoft account and people semi-rioted but came back pretty strong.
It logs app certificate requests which in real life is pretty much equivalent to logging app runs. And that line about only calling the server from time to time is bullcrap. I have years of experience on this issue because my internet is pretty shitty. And that "from time to time" is every couple of hours.