On Mon, Dec 24, 2012 at 3:54 AM, Jeffrey Walton <noloa...@gmail.com> wrote:
> On Mon, Dec 24, 2012 at 5:49 AM, Dan Kaminsky <d...@doxpara.com> wrote: > > Remarkably tricky to do well, though. > Do it like Apple: perform your updates over HTTP. Make it a feature so > an organization trying to manage an non-organizational MacBook can > provide DNS and the Update Service. And don't sign the catalogs (TAR > balls fetched before the signed update). No problems ;) > > What I can't understand: when it was applied against in-App purchases > (StoreKit), Apple cried foul. > > http://z6mag.com/technology/apple/free-apps-for-ipad-iphone-security-flaw-in-ios-goes-unfixed-by-apple-1612248.html > > It would be funny if it wasn't true: "Apple has now added a 'unique > identifier' field to receipts, and given developers tools so they > could verify digital receipts on their own server. However, this only > works if the developer runs the receipt through their server first. > Apps that connect directly to the Apple App Store server are still > vulnerable to the hack." > > Instead of taking advantage of the pre-exisiting relationship between > the StoreKit API and Apple Servers by pinning the certificate (similar > to SSH's StrictHostKeyCheck), Apple pushed it on developers. Amazing. > Like I said: Remarkably tricky to do well Autoupdating third party apps is still an unsolved problem, save for the web where you redownload the client every time (a *wildly successful* approach, as it happens). iOS's third party app updating is a hilariously broken experience.
_______________________________________________ Fun and Misc security discussion for OT posts. https://linuxbox.org/cgi-bin/mailman/listinfo/funsec Note: funsec is a public and open mailing list.
