Given that OpenSSL has supported SHA-2 since 2005, and the Mac App Store was announced in 2010, then released in 2011, I'm really not sure you can blame Apple for thinking it'd be reasonable to expect App Developers to not be using 5 year old versions of dependencies.
Why not? When you're running a service like this, thinking instead of checking is not a wise move.
How much time would it have taken to whip up a script that just tests all of the apps in the store? Even if it's a week of an engineer's time, that seems worthwhile. Testing whether the apps in the store actually run when presented with a valid receipt should already be automated anyway.
The only thing they say about which version of OpenSSL to use is that you need to bring your own and not rely on the one that ships with the OS, because Apple is still shipping a version of OpenSSL from 2005. They do not say anything about which version of OpenSSL you need to use or what capabilities it needs to have.
I bet a lot of people were using Apple's OpenSSL for this originally, and when it was deprecated the path of least resistance would have been to bundle the same version Apple ships.
To be clear Apple's OpenSSL (currently 0.9.8zg) supports SHA2 despite its deprecated status. You can't link against it in El Capitan any more since they stopped shipping the development headers, but getting an OpenSSL that doesn't support SHA2 is actually somewhat challenging (You'd either need an OpenSSL compiled with OPENSSL_NO_SHA or OPENSSL_NO_SHA256 or one that predates 0.9.7h).
None of that excuses Apple not checking this of course. Security.framework can do all this validation -- did they not historically provide code samples on how to do this without linking an external library?
Sorry, I didn't mean to imply that their ancient OpenSSL doesn't do SHA-2, although I had no idea either way. They just say you can't use it because it's deprecated, and therefore off limits to App Store apps.
Historically, I believe the code samples were more or like the ones in the link I posted. I don't believe they ever posted anything that showed how to use Security.framework for the heavy lifting. I think they wanted to get everybody to bring their own code to make it so you couldn't pirate every app with a patch to one shared library.
Interesting, they use a version of OpenSSL that will go EOS at the end of the year? [1] It wouldn't support TLS 1.1 or 1.2, either, unless they've hacked that into their version.
It's not used, exactly. It's more of a historical accident.
Way back when, Apple shipped OpenSSL libraries as part of the OS and included them in the SDK. Naturally, some apps were built that used them.
Then Apple discovered that they couldn't really upgrade the OpenSSL they shipped with the OS, because OpenSSL doesn't maintain binary compatibility. They could ship a new version, but they were stuck shipping the old version as well, and the new version would suffer the same fate.
So instead, they reimplemented what they saw as the important functionality, shipped that as CommonCrypto and Security.framework, and deprecated OpenSSL to try to get people to stop using it. But they still ship it with the OS, because they don't want to break whatever apps do still use it. And they can't upgrade it, because that would defeat the whole purpose of shipping it.
No, it does not ship with 0.9.7. It ships with 0.9.8zg, the absolute latest in the 0.9.8 series. It is unfortunate that 0.9.8 is shipping at all (as it has numerous issues), but Apple has removed the development headers in El Capitan so nothing "new" can link against it now (although apps compiled against it on 10.10 and earlier can still use it). It will be interesting to see what Apple does when 0.9.8 is officially EOL at the end of this year. They may choose to backport fixes (if necessary) or they may just ignore it until 10.12 comes out and they decide to fully remove it.
I am talking about the multiple versions shipped for compatibility with old apps. It is not easy to access, but look for /usr/lib/libssl.0.9.7.dylib I think. I think it is used for apps compiled using Leopard or older SDKs, which I hope no App Store apps are using, but... BTW, back in the PowerPC days they even used to ship with the even older 0.9.6 (only got rid of it when Rosetta was killed).
Ah, yes, those are indeed shipped for ABI compatibility with old apps. Chances are that was last updated the last time 0.9.7 got a release, which would be Feb 2007 I believe (0.9.7m).
Doesn't matter - if you roll out a service, your number one priority is to keep the users happy by keeping your service running. And there's something called testing too - it's not like it was rocket science for Apple to detect problem apps and get that sorted before the SHA-2 rollout. They are taking a 30% cut for crying out loud.
They could even do something really crazy like telling everybody about the change in advance so third-party developers could double-check their code and make sure it still worked.
The expiration date is part of the certificate description. Events like this happen day-in, day-out. "Telling everybody" is not the solution, comprehensive testing is.
The problem wasn't simply the expiration date, but also issuing new certificates with SHA-256 instead of SHA-1. That's a big change you ought to tell developers about when it's their software that had to deal with those certificates.
