MITM to a cisco client

[Daniel Lenski]

On Thu, May 9, 2024 at 1:08 AM David Woodhouse <dwmw2 at 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.