7 ms·

This needs to be upvoted, and the title changed. Turns out it was due to developers using incredibly old security code. Rather than an expired certificate.

• whatever_dude 11y ago
  Yup, this changes my own point of view from "Gee Apple what a blunder" to "Some developers can be really dumb".
  • mikeash 11y ago
    Apple built a lame DRM system, tossed out some half-baked sample code, and then told third parties "OK, you guys go implement this yourselves" without even so much as providing a library to help with the hard parts. Then they made a pretty substantial change without even checking to see if all of these one-off third-party implementations could deal with it.
    • lambada 11y ago
      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.
      • mikeash 11y ago
        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. I'm looking through Apple's guidance here: https://developer.apple.com/library/mac/releasenotes/General/ValidateAppStoreReceipt/Chapters/ValidateLocally.html https://developer.apple.com/library/mac/releasenotes/General... 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.
        • reaperhulk 11y ago
          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?
          • mikeash 11y ago
            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.
            • yuhong 11y ago
              App Store was introduced with Snow Leopard, when it was not depreciated.
          • Natsu 11y ago
            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. [1] https://www.openssl.org/policies/releasestrat.html https://www.openssl.org/policies/releasestrat.html
            • mikeash 11y ago
              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.
      • blinkingled 11y ago
        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.
        • deleted 11y ago
          [deleted]
        • mikeash 11y ago
          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.
          • blinkingled 11y ago
            Yes! Communication is the first measure to try before anything technical as a second line of defense - but that's not a part of Apple's DNA :)
          • rdancer 11y ago
            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.
            • mikeash 11y ago
              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.
  • hockeybias 11y ago
    Apple? blunder? Perish the thought and worship on!
  • blinkingled 11y ago
    You'd be right if the developers were distributing their apps on their own - once Apple has put up a service in the form of the App Store and are taking a 30% cut out of every sale, it's their responsibility to keep it running. If that means detecting that many apps use incompatible OpenSSL and communicating with the developers to address that issue before rolling out SHA-2 cert, so be it - all competent services companies do things like these all the time. It's not as if there wasn't a way for Apple to detect this (if there wasn't then again it's their own fault) and it wasn't as if they couldn't have renewed with another SHA-1 cert for a few months until they figured out how to roll out SHA-2 one without causing a lot of people a lot of trouble.
    • tinalumfoil 11y ago
      > It's not as if there wasn't a way for Apple to detect this Assuming developers were statically linking the old OpenSSH versions, how would Apple detect this? Are developers forced to reveal source code before submitting to Apple? Does OSX executables have some format to specify what libraries it's using? I don't develop for OSX so I'm genuinely curious.
      • JoachimSchipper 11y ago
        Apple is able to scan iOS code for e.g. use of nonpublic API's; certainly they can grep a binary for a recognizable chunk of OpenSSL code, too. (Neither the iOS scans nor the OpenSSL scan will catch everything, of course.)
        • joosters 11y ago
          A recognizable chunk of OpenSSL code? It could be any statically linked and custom-compiled version, that's millions of possible versions, once you take into account compile options, optimisation levels and linking techniques. Good luck grepping for it! Even if the version number is in there somewhere, there's probably all kinds of false positives that you would hit. Plus, it could be due to other SSL libraries, not just OpenSSL. In short, there's no realistic way to do what you are asking.
• deleted 11y ago
  [deleted]