Re: Git via MITM transparent proxy with HTTPS Interception

[Vitaly VS <strikervitaly@gmail.com>]

Thank you for the fast response.

About our network environment
We are Cisco WSA(Servers SW, ASA, ISR) that proxies http/https
traffic. Client requests a website, network device redirects traffic
to WSA using WCCPv2, then WSA proxies the request to Cisco ASA
Firewall and internet.

Yes, that our transparent proxy is not completely transparent because
HTTPS Interception.
If network guys turning off HTTPS Interception for github.com "git
clone" work well through the transparent proxy...

Disabled https interception for github is a security issue for
us(corporate risks, code leak, etc). That's why I asked about can the
git client working with https interception.

Proxy didn't alter any of the contents of the stream(that says to me
our SecOps), but I've not received decrypted traffic yet to be sure.
HTTPS traffic caching but we are also disabled this feature for github.

Common downloads with curl or browser from the same sources from
github or gitlab working well.

Brian, really thank you for pdf but we haven't Client-end TLS
interception on our clients.

ср, 14 апр. 2021 г. в 03:05, brian m. carlson <sandals@crustytoothpaste.net>:

>
> On 2021-04-13 at 12:07:58, Vitaly VS wrote:
> > Hello! Can a Git client work properly through a MITM transparent proxy
> > with HTTPS interception?
>
> Yes, with some important caveats.  The proxy must be completely
> transparent.  It must not modify or impede the data in any way, it must
> speak both HTTP 1.1 and HTTP 2 correctly and fully, and the proxy must
> speak TLS completely correctly, including terminating the connection in
> accordance with the protocol.  It must be completely impossible to tell
> that a proxy is being used.
>
> I do want to point out that TLS interception is by definition a security
> vulnerability and almost always significantly weakens security, often by
> using weaker protocols, breaking or disabling certificate verification,
> and impeding the upgrading and interoperability of the protocol[0].  You
> should definitely read and understand the literature about TLS
> intercepting proxies and have personally verified that your
> implementation is free of vulnerabilities before deploying.  You
> shouldn't rely on your implementer for this information, because they
> usually aren't aware that their implementation has vulnerabilities.
>
> Also, my experience is that many, many proxies of this nature are
> completely broken and don't work correctly, so if you are not fully
> aware of what's going on and haven't fully tested your implementation,
> you shouldn't deploy this technology.  I frequently answer questions
> from users in scenarios such as this who are having problems due to a
> broken proxy and often have to tell them to contact their network
> administrator.  I therefore do not in any sense recommend deploying such
> infrastructure.
>
> Git really does need a properly functioning HTTP and TLS implementation
> and things tend to break in a variety of ways when encountering broken
> proxies.  I would say "exciting ways", but I recognize them all now and
> they're not exciting anymore.
>
> > Getting a bunch of errors when trying to "git clone https://SOME_REPO.git"
> > On small REPOs (about 1-5 MB) there is a chance that the clone will be
> > successful, but mostly I get these errors:
>
> Your proxy is broken and doesn't speak the protocol correctly.  It isn't
> a transparent proxy.  You should either remove it or contact your
> network administrator to have it removed.
>
> [0] https://www.ftc.gov/system/files/documents/public_comments/2016/09/00019-129028.pdf
> --
> brian m. carlson (he/him or they/them)
> Houston, Texas, US