Which bit? I was unaware that I could simply run both mitmproxy as well as rvictl and tcpdump at the same time. However I did just that; inspecting the trace file (in Wireshark) revealed the following (bundle name redacted): [Process Information: com.apple.WebKit(1114) [<CFBundleName>(1111)]] [Id: 1114] [Name: com.apple.WebKit] But I guess you are right in that this does not tell me anything I did not already know. Furthermore I do not see any TLS handshake messages after the server sent its certificate along with the "Finished" message which confirms that there might be some sort of pinning going on.

With mitmproxy you should be able to get the source IP and port number of the request. And you can then use RVI to track the originating process. RVI puts this in packet metadata, which you can display by running tcpdump with the -k option. See the tcpdump man page for details. How would I go about setting that up?

The weird part about this is your suspicion that the traffic is coming from within the web view, but it’s not obvious code running in the web view — so JavaScript, basically — could implement pinning. No, it's not a WebView where I suspect the traffic comes from, but a (mostly) native app that includes a (small) number of 3rd party dependencies in both source and binary form. I suspect the traffic comes from one of the binary dependencies, but I am having a hard time pinning down which one. I only have circumstantial evidence (framework name redacted): $ strings Frameworks/<CFBundleName>.framework/<CFBundleName> | grep google.com mail.google.com www.google.com *.google.com

This is slightly embarrassing, but it turns out that I was using a wi-fi that basically blocks everything except ports 80 and 443. After I changed networks it worked as you described. Regarding the suspicious traffic however I am none the wiser since apparently the connection is secured using some sort of pinning; running mitmdump reveals: client connect server connect google.com:443 (142.251.39.238:443) Client TLS handshake failed. The client disconnected during the handshake. If this happens consistently for google.com, this may indicate that the client does not trust the proxy's certificate. client disconnect server disconnect google.com:443 (142.251.39.238:443)

Thank you for the detailed instructions, I still cannot get it to work though. My Mac is running macOS 15.7.4 and my iPhone is on iOS 26.3.1, but step 9 invariably fails. I even tried messing with the system firewall settings, allowing all incoming connections to mitmproxy and disabling the firewall altogether, but still no luck.

I haven’t tried mitmproxy recently, but the last time I did it worked a treat. I don't know what I'm doing wrong honestly, but if I configure a manual HTTP proxy I always end up with "No Internet Connection"

Yes, that's the first thing I tried after tcpdump when I saw there were encrypted QUIC packets in the trace file. I could not get my device to connect to mitmproxy running on my Mac though, and running Proxyman directly on the device did not capture anything interesting.

I have, but the HTTP Traffic Instrument does not seem to record anything, I just get Network Connections:

I also have been perusing the logs, but to no avail (Bundle Name and ID redacted): default 2026-03-06 08:10:29.582324 +0100 mDNSResponder dnssd_server [R421] getaddrinfo start -- flags: 0xC000D000, ifindex: 0, protocols: 0, hostname: google.com, options: 0x8 {use-failover}, client pid: 545 (com.apple.WebKi), delegator pid: 463 (<CFBundleName>) default 2026-03-06 08:10:29.583518 +0100 mDNSResponder resolver [Q65194] Received acceptable 44-byte response from 192.168.179.1 over UDP via en0/13 -- id: 0x533C (21308), flags: 0x8180 (R/Query, RD, RA, NoError), counts: 1/1/0/0, google.com. IN A?, 285 IN A 172.217.17.206 default 2026-03-06 08:19:53.020864 +0100 com.apple.WebKit.Networking connection [C1 83F90D07-2D61-4158-A073-C82071955008 google.com:443 quic-connection, bundle id: <CFBundleIdentifier>, url: https://google.com/, definite, attribution: developer, context: com.apple.CFNetwork.NSURLSession.{FC11B685-7D67-4806-80B1-6E2559DC8AA4}{(null)}{Y}{3}{0x20e0344a0} (sensitive), proc: 1F873F6E-9E6F-3D35-A95D-C72E62C50C26, effective proc: 888D3A38-707B-33BC-944C-0143FC68835D, delegated upid: 0, pid: 814, attribution context: google.com] start info 2026-03-06 08:19:53.024946 +0100 com.apple.WebKit.Networking connection nw_endpoint_resolver_handle_alternative [C1.1.1 google.com:443 in_progress resolver (satisfied (Path is satisfied), interface: en0[802.11], ipv4, dns, uses wifi, LQM: good)] Discovered alternative google.com:443 using tcp info 2026-03-06 08:19:53.024960 +0100 com.apple.WebKit.Networking connection nw_endpoint_resolver_handle_alternative [C1.1.1 google.com:443 in_progress resolver (satisfied (Path is satisfied), interface: en0[802.11], ipv4, dns, uses wifi, LQM: good)] Discovered alternative google.com:443 using quic info 2026-03-06 08:19:53.024986 +0100 com.apple.WebKit.Networking connection nw_endpoint_transform_receive_report_block_invoke [C1.1 google.com:443 in_progress transform (satisfied (Path is satisfied), interface: en0[802.11], ipv4, dns, uses wifi, LQM: good)] updated endpoint alternatives allow quic, restarting default 2026-03-06 08:19:53.029119 +0100 com.apple.WebKit.Networking quic quic_conn_initialize_inner [C1.1.2.1:2] [-987721dfe9544d2a] created QUIC connection (spin bit enabled) info 2026-03-06 08:19:53.100833 +0100 com.apple.WebKit.Networking quic quic_conn_process_inbound [C1.1.2.1:2] [-f87721dfe9544d2a] unable to parse packet (decryption keys may not be ready)

It seems to be QUIC explicitly. And it's not us using it but some dependency we include - and yes, I am aware of https://developer.apple.com/documentation/Xcode/verifying-the-origin-of-your-xcframeworks :)

What platform are you on? iOS unfortunately Oh, and are you using QUIC via HTTP/3? Or explicitly? I'm not sure; let me check

It does, and the exception reason tripped me up at first: Exception Type: EXC_BAD_ACCESS (SIGKILL) Exception Subtype: KERN_INVALID_ADDRESS at 0x0000000000000000 Exception Codes: 0x0000000000000001, 0x0000000000000000 VM Region Info: 0 is not in any region. Bytes before following region: 4339253248 REGION TYPE START - END [ VSIZE] PRT/MAX SHRMOD REGION DETAIL UNUSED SPACE AT START ---> __TEXT 102a3c000-102a40000 [ 16K] r-x/r-x SM=COW /var/containers/Bundle/Application/5BD67EC6-39CC-428C-944B-C2E2FCA311B4/<private>.app/<private> Termination Reason: CODESIGNING 2 Invalid Page Turns put it was likely a problem with an async closure passed to a Combine subject as indicated by the first stack frames: 0 ??? 0x0000000000000000 0x0 + 0 1 <private> 0x0000000102edacc8 type metadata accessor for (nonisolated(nonsending) (), ()) + 44 (/<compiler-generated>:0) 2 <private> 0x0000000102edac64 type metadata accessor for PassthroughSubject<(nonisolated(nonsending) (), ()), Never> + 44 (/<compiler-generated>:0)

So, the code under test takes a trust object (SecTrust) and returns an allow / deny decision based on the public keys in the certificates in the chain? Exactly If so, you could solve this problem by having you test hardness create the trust object using the basic X.509 policy (SecPolicyCreateBasicX509()) rather than TLS policy (SecPolicyCreateSSL(::)). We are in fact using SecPolicyCreateSSL(_:_:). I'll try SecPolicyCreateBasicX509() and report back. ps You’re probably aware of this, but ATS supports public key pinning via the NSPinnedDomains property. If that works for you, it’s a lot easier than doing this in code. I know (and I've lobbied for it), but we are required to support HPKP.

We have a custom implementation of HTTP Public Key Pinning on top of App Transport Security. The code in question tests this implementation (i.e. that given a valid trust object performing pin validation either lets our custom trust evaluation fail or succeed).

Thanks Quinn; I'll file this under "think first, ask later"