The part that isn't magic

HTTPS is designed so that nobody between your device and a server can read the traffic — that's the entire point of TLS. So when a tool on your own iPhone or Mac shows you the decrypted body of a request, it's worth being precise about what's actually happening, because it isn't breaking encryption. It's a man-in-the-middle, performed with your own explicit, revocable consent, on your own device.

Here's the mechanism, and it's identical on iOS and macOS: your device trusts a fixed list of certificate authorities to vouch for who a server is. When you install and trust a new root certificate — Hollowport's, Charles's, Proxyman's, it doesn't matter which — you're adding one more authority to that trusted list, one that happens to run locally on your own device. Traffic from an app you're testing gets intercepted by an on-device proxy, which presents its own certificate (signed by that new trusted authority) instead of the real server's. Your device accepts it, because you told it to trust that authority. The proxy decrypts the request, shows it to you, then re-encrypts it and forwards it on to the real destination.

Why this needs your explicit action

None of this works silently, on either platform — but the concrete steps look different, because trusting a new certificate authority is handled by different parts of each OS:

  • iOS: install a configuration profile, then flip a second, separate toggle under Settings → General → About → Certificate Trust Settings. Two deliberate steps, not a background permission.
  • Mac: the certificate goes into Keychain Access instead of a Settings app — you add it to the login or System keychain, then open it and set "When using this certificate" to Always Trust for SSL. Different app, same idea: an explicit, per-certificate trust decision you make yourself.

That's deliberate on Apple's part, not an inconvenience a tool is imposing on you: the platform wants it to be obvious and reversible whenever a device starts trusting a new authority capable of this.

It's also fully local on both platforms. A well-built on-device interception tool doesn't route your traffic through a remote server to do this — the proxy runs on the device itself, so the only thing that ever sees your decrypted traffic is the device it's already on.

Where the platform draws a line: certificate pinning

Some apps don't rely on the device's trusted certificate list at all — on iOS or Mac. Instead, they hard-code exactly which certificate (or public key) they'll accept, and reject everything else, including a newly trusted local authority. This is called certificate pinning, and it's common in banking apps and in Apple's own system traffic (push notifications, iCloud Private Relay).

Pinned traffic is visible at the connection level to an interception tool — that a connection happened, when, to where — but the content stays opaque no matter how the certificate is configured. This isn't a bug or a missing feature in any particular tool; it's the app deliberately opting out of exactly the mechanism described above, and no on-device or off-device proxy can override that without modifying the app itself. See Capabilities & Limitations for exactly how this compares to other traffic types Hollowport does and doesn't have visibility into.

Reversing it

Because the whole mechanism depends on one trusted certificate, undoing it is equally simple, wherever it was granted. On iOS, delete the profile under Settings → General → VPN & Device Management. On Mac, remove or distrust the certificate in Keychain Access. Either way, decryption stops immediately — there's no residual state, and the device just goes back to trusting only the certificate authorities it shipped with.

If you want to see the iOS side of this in practice, without a separate machine, Hollowport's certificate setup guide walks through both steps.