Maximilian Hils

There's still nothing in the PCAP that would explain the issues you are describing.

> "The revocation function was unable to check revocation because the revocation server was offline." This indicates that there is some attempt (DNS traffic, TCP connection, ...) from the client...

Thank you! Much more useful and interesting. It looks like your client sends the initial request to mitmproxy on port 8080, but then tries to fetch the CRL directly by...

Thank you, this is super useful feedback! - We have a new docs layout inbound that should improve things a bit: https://docs.mitmproxy.org/dev/. Would it be useful to rename "Addon Development"...

Using mitmproxy itself as a library is unsupported. There are no technical reasons why it can't be done, but there is no API stability whatsoever and no documentation.

@ks07: You can change the upstream proxy using the scripting API: https://github.com/mitmproxy/mitmproxy/blob/master/examples/complex/change_upstream_proxy.py. On a technical level skipping and changing are quite different, so let's keep this feature request at the...

This is a great idea! I thought about this as well when implementing local capture mode. The good news is that it's done on the Rust side, the bad news...

As mentioned in #7609, adding a CRL is required for certain clients. So if we want to support these clients out of the box, we need to add _some_ CRL....

> the magic should not indicate the usage of mitmproxy so obviously. mitmproxy proactively identifying itself is WAI.

> It should not be the case for a client, though, e.g. a malicious actor checking the server certificate. You're having it backwards: The threat model here is someone using...