seanmonstar
Make it easier to allow SSLKEYLOGFILE usage
Is your feature request related to a problem? Please describe.
Imagine, for the sake of argument, that you're debugging something like rust opentelemetry and you don't know where someone is creating an HTTP client (or you don't want to patch that). And you've observed in some production-adjacent environment where grabbing a new binary is hard that somewhere, somehow it's sending bogus HTTPS traffic and the information you need isn't in the logs, so you yearn for a usable packet capture.
If the application were libcurl, chromium, or Python based, you could just set the SSLKEYLOGFILE environment variable, dump the keys, tcpdump the packets and stare at the problem in wireshark. It would be done in 2 minutes without recompiling anything.
In Rust software, it's necessary to find someone else's http client instantiation and patch it, taking a minimum of 15 minutes (assuming that one can even build the software from source at all). This is really painful and affects operators significantly more than developers across the Rust ecosystem as the patch necessary to dump session keys requires copy-pasting a lot of complex initialization code (which is kind of unsafe to vendor in binaries going to production lest the defaults for unrelated settings change) and is nontrivial to apply, restricting it to being most feasible to developers only.
Rust is not unique in having non-debuggable HTTPS; it shares this trait with go and haskell.
Describe the solution you'd like
I ideally want the default TLS setup for reqwest for all supported backends to, by default, read the SSLKEYLOGFILE environment variable and write the session keys in the pointed-to file, like libcurl does without any ability to disable it. I don't know if anyone's even asked for this to be possible to disable, given that there is no knob to disable it.
https://github.com/curl/curl/blob/fca1fdc988bd5d8573c4d38aaeae09f22e93ea5d/lib/vtls/keylog.c#L49-L65 https://github.com/curl/curl/blob/fca1fdc988bd5d8573c4d38aaeae09f22e93ea5d/lib/vtls/openssl.c#L1838
Describe alternatives you've considered
If, for some reason, it is still undesirable to implement this observability feature by default, it would be very helpful to at least provide a helper method to enable it.
I've tried patching the binary in memory (not a joke!) to hook the NoKeyLog impl to log keys: https://jade.fyi/blog/announcing-clipper/
I've tried chasing the bug through the application and having to vendor every involved package. This experience was so bad that I wrote clipper to patch the executable in memory instead.
I've tried stuff like mitmproxy; it was defeated by webpki-roots ignoring my system ca store in a very commonly used configuration that ignores the big warning in the readme: https://github.com/rustls/webpki-roots?tab=readme-ov-file#warning, alongside, presumably, the application also not having a standard way to set the proxy that works on everything.
I've tried a debugger.
None of these, in the end, really make "someone else put an http client in my app or someone else's app and I don't know where it is" very easy to debug.
I see someone has described the practically Goldbergian method for doing this in the last issue because one has to recreate a whole bunch of the TLS setup oneself: https://github.com/seanmonstar/reqwest/issues/1016#issuecomment-2650337801
Additional context Add any other context or screenshots about the feature request here.
N.B. The reason I am cutting reqwest a ticket rather than rustls or hyper-tls (which isn't always used in reqwest afaict) is because openssl also does not apply policy around the key log itself, that's supposed to be in the HTTP client like Curl. Analogously, reqwest is the lowest-level library where you have multiple TLS back-ends and a reasonable expectation to apply default policy like supported TLS versions, ciphersuites, key logging behaviour, etc, and have a consistent interface across multiple TLS implementations for exposing such things.
It's mostly reasonable that rustls does not apply any particular opinions on key logging other than providing sample implementations for logging to a file or not logging. This is approximately what Haskell tls does as well. But it means that reading the environment variable should be in the join point of all the TLS libraries, namely reqwest.
I'd be in favor of adding a method to ClientBuilder, which if enabled installs the environment-variable-reading logger. This would be similar to the existing ClientBuilder::connection_verbose(), which can print the raw IO bytes (pre-encrypted), but requires both code and environment to opt-in, for protection.
I realize that is a hurdle for some people who wish they could just enable debugging when reqwest is used multiple dependencies deep, but such is the constant balance of security vs convenience.
