git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: "brian m. carlson" <sandals@crustytoothpaste.net>
To: Vitaly VS <strikervitaly@gmail.com>
Cc: git@vger.kernel.org
Subject: Re: Git via MITM transparent proxy with HTTPS Interception
Date: Wed, 14 Apr 2021 11:49:10 +0000	[thread overview]
Message-ID: <YHbWtlJDSyuAO+vf@camp.crustytoothpaste.net> (raw)
In-Reply-To: <CAEaE=izSNyxRcvMd5bArHnmi0F2G83nouge9e_qxiQmA0AsWog@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 4180 bytes --]

On 2021-04-14 at 09:35:48, Vitaly VS wrote:
> 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...

Yes, that's because you're tampering with the data.  The output you're
getting clearly indicates something is modifying the data.  TLS normally
protects the data from accidental as well as intentional errors, so
there's no situation in which this could be an accident but for your
proxy.

Git will work in this case if and only if your proxy does the things I
told you, which your proxy doesn't.  It isn't a transparent proxy, since
that by definition requires that requests and responses are not
modified.

I do appreciate you mentioning the proxy you're using so we can include
it as a known broken proxy in future versions of the Git FAQ.

> 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.

Many major companies manage to avoid these risks without introducing
security holes into their network and breaking common applications that
speak standard protocols by avoiding using TLS-intercepting proxies.  In
fact, I've worked at a company which was very diligent about these
matters and had strict policies on them, and in no situation did we
intercept TLS traffic.

> 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.

Git sends data that is compressed but not using a normal compressed
archive format.  Thus, if you do anything that inspects the data to see
if it is "malicious" or "inappropriate," your technology will likely
flag data that just happens to have a byte sequence that collides with
something that you think is bad.  For example, if you flag the text
"sex" because you think it is inappropriate, then the probably is about
1 in 2^24 that sequence will appear in the stream and you will break the
protocol, since compressed data often appears random.

This is, I suspect, why Git tends to break in situations where other
programs do not.

If you want Git to work reliably, you can never modify the data of the
stream, no matter what.  You also can't buffer the stream (for
example, try to turn chunked encoding to non-chunked).  This is
something you're going to have to accept; bargaining isn't going to work
here, no matter how much you want it to.

I can't force you to listen to me here, but I strongly recommend that if
you don't, you clearly communicate to your users using Git what you're
doing and that you know this will break Git so other parties don't have
to.  I'm sure that the support teams for GitHub and GitLab will tell you
that it's your proxy and that you have to remove or disable it just as I
am here.

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

Here are some articles covering hardware middleboxes as well:

https://blog.cloudflare.com/monsters-in-the-middleboxes/
https://jhalderm.com/pub/papers/interception-ndss17.pdf

I should point out that this problem is so pervasive that TLS 1.3
includes intentional countermeasures against some of the worst practices
of TLS middleboxes.  I'm certain that most of the TLS working group
would prevent TLS middleboxes from working at all if they could find a
way to do so, and many of those people are at the vanguard of Internet
security.
-- 
brian m. carlson (he/him or they/them)
Houston, Texas, US

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 263 bytes --]

  reply	other threads:[~2021-04-14 11:49 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-04-13 12:07 Git via MITM transparent proxy with HTTPS Interception Vitaly VS
2021-04-13 12:24 ` Jason Pyeron
2021-04-14  0:05 ` brian m. carlson
2021-04-14  9:35   ` Vitaly VS
2021-04-14 11:49     ` brian m. carlson [this message]
2021-04-14 12:29       ` Jason Pyeron
2021-04-14 15:41         ` Vitaly VS

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=YHbWtlJDSyuAO+vf@camp.crustytoothpaste.net \
    --to=sandals@crustytoothpaste.net \
    --cc=git@vger.kernel.org \
    --cc=strikervitaly@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).