←back to thread

Httptap: View HTTP/HTTPS requests made by any Linux program

(github.com)
664 points alexflint | 1 comments | 03 Feb 25 16:28 UTC | HN request time: 0.336s | source
Show context
wzyboy ◴[03 Feb 25 20:00 UTC] No.42922184[source]▶
It's a genius idea to run the process in a isolated network namespace!

I'm more interested in the HTTPS part. I see that it sets some common environment variables [1] to instruct the program to use the CA bundle in the temporary directory. This seems to pose a similar issue like all the variants of `http_proxy`: the program may simply choose to ignore the variable.

I see it also mounts an overlay fs for `/etc/resolv.conf` [2]. Does it help if httptap mounts `/etc/ca-certificates` directory with the temporary CA bundle?

[1] https://github.com/monasticacademy/httptap/blob/cb92ee3acfb2...

[2] https://github.com/monasticacademy/httptap/blob/cb92ee3acfb2...

replies(2): >>42923006 #>>42923998 #
1. adtac ◴[03 Feb 25 22:12 UTC] No.42923998[source]▶
IMO there's no general solution to the HTTPS part that will work for all kinds of programs and the long tail of certificate pinning implementations.

As a proof by counterexample, imagine malware that uses TLS for communication and goes to great lengths to obfuscate its compiled code. It could be a program that bundles a fixed set of CA certificates into its binary and never open any files on the filesystem. It can still create valid, secure TLS connections (at least for ~10 years or so, until most root CA certificates expire). TLS is all userspace and there's no guarantee that it uses OpenSSL (or any other common library), so you can't rely on hooking into specific OpenSSL functions either. If the server uses a self-signed certificate and the client accepts it for whatever reason, it's worse.

With that said, it's definitely possible to handle 99% of the cases reliably with some work. That's better than nothing.