Maximilian Hils
Maximilian Hils
I don't think there is a good way how we can fix this. Isn't this something that every dual stack server is going to see?
This may be because we're not completing both TCP handshakes here. With UDP we don't have a handshake, so we have a "connection" immediately.
> Agreed, but for QUIC flows we ideally shouldn't be showing the second "client connect" Not sure - there is a connection after all? The part I'm more interested in:...
> Tested out the time it takes to do the server handshake and on linux it is around 30ms while on windows its around 300ms. This is not ideal indeed....
> This takes around 250ms on windows and 20ms on linux. 🤯 Is this only for the first request going through the proxy, or for every request?
I'd expect handshake crypto to be slow, but not that slow. 😬 @jlaine, do you have any ideas on what could take 250ms here?
Can I ask what your use case here? One problem we have with mitmweb here is that there can be multiple instances running, and we obviously don't want to sync...
Bisected to be56a0af1f825d6c352bbc818f617098a5a4d76c, /cc @errorxyz
I think the correct fix here is to handle HttpConnectErrorHook in the termlog addon. Note that mitmproxy and mitmweb don't show anything in the flow list either (only in the...
Did you read https://docs.mitmproxy.org/dev/concepts/certificates/#using-a-custom-server-certificate?