Comment by londons_explore 10 months ago
Apple could say "If you wanna talk HTTPS, you have to use our HTTPSClient class, and that only supports using the system certificate store and does not support pinning".
Or they could say "All apps that don't support custom certificates for https will be denied app store approval".
A better rule might be "You must use our HTTPSClient class, and it either uses the system+user trust stores, or optionally it uses an application supplied certificate authority+the user trust store".
Or you could ignore the self-signed aspect altogether, and instead give the OS VPN framework (where all network introspection stuff lives on iOS) a hook into the forced-choice HTTPS client — a hook that allows the active system VPN to say either “show me that before you encrypt it / after you decrypt it” or “don’t bother encrypting/decrypting that; I’ll handle it.”
Where, in the latter case, the TLS establishment is opaque, but then the VPN is handed the data that would be going through the TLS logic, plus an (also-opaque) handle to the established TLS-session RSA key, that it can use to finish the encryption/decryption process of each stream-chunk on behalf of the app, after doing whatever filtering / transformation / etc. it wants to do.
(Anyone remember Privoxy, the “MITM that works for you” that presaged most of the in-client features of Tor Browser? Same idea; just now with OS support.)
While you're at it, make sure to have them prohibit any encryption on top of HTTPS, or apps might just be hiding things in application-level encryption schemes!
Banning certificate pinning... Do we really need mandated insecurity by prohibiting apps from doing better than trusting all Apple-trusted CAs around the world?