4 ms·

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 f

by 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.
      - 11y ago
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.

by lambada 11y ago

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.
    - 11y ago

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.