On Thu, May 9, 2024 at 1:08 AM David Woodhouse <dw...@infradead.org> wrote: > On Wed, 2024-05-08 at 17:59 -0600, Oscar Velazquez wrote: > > I have a hunch: it is to change server-cert-hash, but I do not know > > what the correct values could be or if this is a valid approach. > > Any help would be appreciated. > > > > Probably the sha1 fingerprint of the (real) server's SSL certificate.
Yes indeed. > In http://david.woodhou.se/proxy.go there's support for changing such a > hash to the hash of the cert you're using for the proxy itself. I would recommend using *mitmproxy* for this purpose, because I contributed support for making this much easier there back in 2017. 😄 In https://github.com/mitmproxy/mitmproxy/commit/391f28f78cf9f4ee2f82c69c7f5ce370b69b77cd, I added support for extracting the MITM proxy's certificate in a script. You can see an example of this in use in my jun_ssl_log.py script (https://gist.github.com/dlenski/33bfa3a8691686d02ddaf7a51843a89a#file-jun_ssl_log-py-L42-L44) which I used a bunch for MITM'ing Juniper clients. In addition to trying to *rewrite* the <server-cert-hash> tag, you might also want to try simply *removing* it from the returned XML. That's what I did in a similar context in the gp_ssl_log.py (https://gitlab.com/dlenski/pangp-hacks/-/blob/master/gp_ssl_log.py?ref_type=heads#L63-68) for MITM'ing GlobalProtect clients, and it worked fine. The proprietary clients tend to have fail-open/permissive-by-default fallbacks when their anti-MITM information is removed or disabled. More details at https://www.infradead.org/openconnect/mitm.html#antimitm. _______________________________________________ openconnect-devel mailing list openconnect-devel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/openconnect-devel
