We have a use case where we need to hijack an HTTPS connection before MITM occurs, examine the headers and other data on the CONNECT request, and potentially take one of two paths based on our business logic:
a) Send a custom raw HTTP response and close the connection, or:
b) Take the normal goproxy HTTPS MITM path
This is easy to do with a normal ConnectHijack action if we don't desire MITM, but in this case we do desire MITM and can't seem to figure out how to accomplish what we need with the ConnectMitm action.
I think it would be possible to for us to submit a patch, which adds, for example, a HijackMitm function on the ConnectAction, and if it's present, then invoke it here and either return or continue the normal MITM process based on the result of that function.
Does that sound like a reasonable approach / would a patch like that be welcome? Or is there a better way to handle this problem?
We have a use case where we need to hijack an HTTPS connection before MITM occurs, examine the headers and other data on the CONNECT request, and potentially take one of two paths based on our business logic:
a) Send a custom raw HTTP response and close the connection, or:
b) Take the normal goproxy HTTPS MITM path
This is easy to do with a normal
ConnectHijackaction if we don't desire MITM, but in this case we do desire MITM and can't seem to figure out how to accomplish what we need with theConnectMitmaction.I think it would be possible to for us to submit a patch, which adds, for example, a
HijackMitmfunction on theConnectAction, and if it's present, then invoke it here and either return or continue the normal MITM process based on the result of that function.Does that sound like a reasonable approach / would a patch like that be welcome? Or is there a better way to handle this problem?