HTTPS is sufficient against MITM, until someone disables all verification to use their self-signed cert, or adds their poorly-secured "CA" cert to the allowed CA's for the download, or adds a weak cipher to the list. Do you trust every app developer to do those right (if they even use HTTPS!)[0], or would you rather trust Apple to get it right in the centralized system they designed for app updates for all apps?

I'm not even fond of Apple, but I'd rather trust them, and I'm glad they're protecting their users.

[0] Caveat: I don't know how likely/possible these are to occur on iOS. I assume a sufficiently motivated & misguided developer could do them within their own app's context.

> Do you trust every app developer to do those right (if they even use HTTPS!)[0]

If I'm running an app that includes native code and accesses data from the outside world then I'm probably trusting that app developer to write C code that doesn't contain arbitrary code execution vulnerabilities, which is much much harder than using HTTPS right.

"HTTPS is sufficient against MITM, until someone disables all verification to use their self-signed cert, or adds their poorly-secured "CA" cert to the allowed CA's for the download, or adds a weak cipher to the list. "

Or that attacker controls or can coerce a Certificate Authority in the OS's root list - like, say, just about any nation state...

Most apps - I suspect - are not pinning their TLS certs. Apple have already gotten onto a very public fight with the FBI.

You see, this whole thing:

"Even if the remote resource is not intentionally malicious, it could easily be hijacked via a Man In The Middle (MiTM) attack, which can pose a serious security vulnerability to users of your app."

Basically says "only we, Apple, can do HTTPS right, you can't, and even if you try you can easily be MiTMed". Which is I don't agree with.

What you say is correct, but it's not the argument I criticize. You point is that they don't trust developers to implement secure loading of code and don't have technical means to control it and can't or don't want to check it in the review. But it's completely different to "you could be easily hijacked if you're not Apple".

I'd trust Apple to do right more than I'd trust a small team at a startup trying to deliver features at breakneck speed. I really like the fact that Apple is looking out for its customers here.

In an ideal world where apps check/pin certificates and don't disable cert checks to make self-signed certs work in test environments you'd be right. If only this were reality.

I suspect I've left a lot of test devices behind me with Charlesproxy MiTM root certs installed (I wouldn't be _too_ surprised if one of the phonee in my pocket right now has that...)

I'm just pointing out that "remote resource ... could easily be hijacked via a MiTM attack" is technically incorrect. The problem is not the remote resource per se, the problem is trusting developers to implement secure loading of resources. Which is a completely different argument.

Depends on who you're expecting the MiTM attack to be executed by.

Are _you_ secured against, say, an attacker who works at Verisign and can create a valid cert for api.yourdomain.com? Or an attacker who has a buddy who works at GoDaddy who can subvert your dns records so they can trick LetsEncrypt into issuing a valid cert for api.yourdomain.com? Or an elbonian teenage hacker who's just got your AshleyMaddison assword from pastebin and used it to log into your Gmail account and overtaken your dns registrar account to get themselves a valid ssl cert?

And all of this is "easily"?

Like I said - depends on who you are.

For me? Not really "easily" (tho a wifi pineapple in a coffee shop where FE Devs hang out attempting to MiTM them with the Charlesproxy root CA would be a fun experiment... Which, of course, I'd never do - because that'd be bad, right?)

For someone at the NSA or CIA or Mossad? Sure it's easy. For someone a little further down the LEO "cyber" chart like FBI, probably not "easy". For a local beat cop or council dog catcher - nah, definitely not "easy".

For a very-dark-grey pen tester or redteam who're prepared to phish your email password and use it to p0wn your dns registrar? They'd probably call that "easy"... (Hell, I've got a few pentesting friends who'd call that "fun"!)