[punnerud]

I wish they could break Snapchat, Facebook etcs ‘s self-signed certs. I own the device, why can’t I see the traffic to and from all of these apps if I add my self-signed cert and approve to use a MITM-proxy.

Most apps work, but not everyone.

Often called certificate pinning.

[tadfisher]

Apple isn't doing certificate pinning, it's the apps verifying the certificate chain themselves by baking in public keys (or hashes/fingerprints). So there's not really a way for Apple to break this.

[londons_explore]

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".

[lxgr]

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?

[saagarjha]

They already do that to some extent, actually. Not as you mention, but because of US export compliance laws.

[lxgr]

Countless encrypted messenger apps, GPG implementations etc. beg to differ.

[saagarjha]

Beg

[londons_explore]

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".

[derefr]

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.)

[tadfisher]

The only way to "not support pinning" is to prevent apps from inspecting the certificate chain. This will break much more than pinning.

[jesterson]

Why they would do that? They can't care less about what end user want, particularly in context we are discussing

[moduspol]

Actually it depends. Apple does provide a way to configure your app for certificate pinning, which then allows you to pin certificates without any changes in your code. [1]

Any apps that set up certificate pinning this way could be bypassed by Apple, though obviously there would be little value in them doing it since that'd just lead to app developers doing what you're describing instead.

Though if I'm understanding this correctly, jailbroken phones could probably bypass it by modifying an app's Info.plist and running the app despite the broken signature.

[1] https://developer.apple.com/news/?id=g9ejcf8y

[qingcharles]

Can you not extract the key from the apps? They are only signed against modification, surely? Can you not read the data they have stored on the handset?

[darknavi]

Generally apps like Fiddler generate their own cert which you load onto the device and accept. My understanding is this allows it intercept and re-write requests. When you do this, apps using cert. pinning will sniff out your "wrong" cert. and stop working.

[kstrauser]

No, the idea is that the app has the server's public key embedded in them, and they use that to verify that they're connecting only to the server with the corresponding private key.

[benmmurphy]

If you jailbreak your phone then you are able to remove certificate pinning. If you just want to do this for research purposes then you can buy an old iPhone6s, iPhone8 or iPhoneX and use checkra1n which uses a bug early in the bootchain in order to jailbreak the phone. I think palera1n is based on checkra1n and might have better support for newer iOS versions: https://palera.in/

[saagarjha]

No need to jailbreak to remove pinning; you just need to patch the app itself (for example, by replacing the certificate it verifies against or the code that does the verification).

[benmmurphy]

you need some way to decrypt the app store app so you know what you are modifying and so you can resign which usually involves a jailbreak. maybe there are these apps that only have the first page encrypted so potentially you don't need to decrypt these apps because you can guess what the first page is.

[hummusFiend]

Ownership philosophy aside, it's funny that you pick those two companies as examples.

The former enabled cert pinning (partially) as a response to a MITM[1] from the latter.

[1]: https://arstechnica.com/tech-policy/2024/03/facebook-secretl...

[mmd45]

i saw a video on youtube where a guy intercepted https app traffic from an android app for a smart scale where the app used certificate pinning. there was some very automated tool for defeating the cert pinning. unfortunately i can't find the video link.

[captn3m0]

Probably objection, which uses Frida internally. Unfortunately, it depends on the implementation. It patches Java X509 classes, but some apps don’t use that.

The biggest pain is Flutter apps, which come with their own native TLS stack.