[Feature Request] - Dump TLS Session keys + decrypt traffic

[eyJhb]

I rarely need to modify a request/response, and am only really interested in seeing the requests/responses being made.
Besides this, I see many apps that do cert pinning where the most up-to-date techniques to circumvent them do not work.

So I purpose that instead it would be possible to dump the TLS session keys, and then using these to decrypt the traffic afterwards.
This is currently really easy/feasible on iOS, since many apps just using libboringssl, and can be done like so:

• https://github.com/jankais3r/Frida-iOS-15-TLS-Keylogger/blob/main/ios-tls-keylogger.js
• https://github.com/fkie-cad/friTap/blob/main/agent/ios/openssl_boringssl_ios.ts

I'm no expert in how httptoolkit works, or if this is a feature that is even wanted, but it is one I would like to see.
My idea would be to still use the proxy server, to get all the encrypted traffic, and use the anti-root detection bypass scripts combined with one that dumps the TLS session keys.

The proxy should then not do MITM, but only decrypt it using the provided keys. I'm very unsure how this works, as I've only played with it using Wireshark before.

Does this make sense? I could in theory help work on this, but the biggest hurdle would really be the proxy and decryption, which I haven't looked at yet.

[pimterry]

Decryption from raw data + keys like this is definitely neat, but I think it doesn't fit well into HTTP Toolkit's model (very focused on interactive interception, with a lot of tools & UX built around this).

We certainly could use Frida and automate with the scripts here through that, but if you're doing this then you might as well just use Frida to disable the cert pinning entirely (which is exactly what we do with the automated Frida setup for rooted Android & jailbroken iOS: https://github.com/httptoolkit/frida-interception-and-unpinning/blob/main/native-tls-hook.js). As far as I know, this works for all cases using libboringssl already - it's the same hook target, it's just that instead of attaching a keylogger, we change the trusted keys instead, which effectively overrides the system trust configuration and any app certificate pinning that's applied.

This doesn't cover 100% of other cases, but almost all scenarios where this doesn't work (very strict protections against Frida, and custom or very unusual TLS code that doesn't use the standard boringssl approach) this kind of keylogging also won't work.

It is the kind of thing we could probably add later as an import option though (import a PCAP and keys and we'll extract to HTTP traffic automatically). We'd need a processing layer for that, but that's plenty of off the shelf libraries doing this I think, PRs welcome if you'd like to try to integrate one.

[eyJhb]

That makes perfect sense, and I appreciate the insight into this. I didn't want to start investing time into a PR, before I knew what the stance was on it. And it seems like it could be a "fun" to have feature, but not something that would be a priority, which I get.

My initial want for this was, that I tried to investigate the traffic from Lidl Plus, but it didn't seem to work at all. But the more I think about it, the more I suspect that the proxy is doing something wrong with the QUIC traffic. Because it doesn't have any smart Frida detection, and it does use libboring.

Does HTTPToolKit just forward QUIC , or does it actually break it at the moment?