Git via MITM transparent proxy with HTTPS Interception

Git via MITM transparent proxy with HTTPS Interception

[Vitaly VS]

Hello! Can a Git client work properly through a MITM transparent proxy
with HTTPS interception?

Is there any documentation or recommendations on how to configure a
MITM proxy with HTTPS interception for the Git work?

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:

git clone https://github.com/aaptel/wireshark.git
Cloning into 'wireshark'...
remote: Enumerating objects: 524729, done.
fatal: protocol error: bad line length character: ??:s00 KiB/s
error: inflate: data stream error (invalid literal/lengths set)
fatal: pack has bad object at offset 2093488: inflate returned -3
fatal: index-pack failed

git clone https://github.com/aaptel/wireshark.git
Cloning into 'wireshark'...
remote: Enumerating objects: 524729, done.
fatal: protocol error: bad line length character: ????06 MiB/s
error: inflate: data stream error (incorrect data check)
fatal: pack has bad object at offset 17119052: inflate returned -3
fatal: index-pack failed


git clone https://github.com/aaptel/wireshark.git
Cloning into 'wireshark'...
remote: Enumerating objects: 524729, done.
error: RPC failed; curl 56 Malformed encoding found in chunked-encoding
fatal: the remote end hung up unexpectedly
fatal: early EOF
fatal: index-pack failed

git clone https://github.com/Homebrew/brew.git
Cloning into 'brew'...
remote: Enumerating objects: 148, done.
remote: Counting objects: 100% (148/148), done.
remote: Compressing objects: 100% (80/80), done.
Receiving objects:   3% (6247/180213), 2.64 MiB | 1005.00 KiB/s
Receiving objects:   4% (8247/180213), 3.75 MiB | 1.00 MiB/s
Receiving objects:   5% (9011/180213), 4.47 MiB | 1.05 MiB/s
fatal: protocol error: bad line length character: ?V?V7 MiB/s
error: inflate: data stream error (incorrect data check)
fatal: pack has bad object at offset 6558416: inflate returned -3
fatal: index-pack failed
error: RPC failed; curl 56 Malformed encoding found in chunked-encoding

git clone https://github.com/Homebrew/brew.git
Cloning into 'brew'...
remote: Enumerating objects: 148, done.
remote: Counting objects: 100% (148/148), done.
remote: Compressing objects: 100% (80/80), done.
Receiving objects:   0% (1/180213)
Receiving objects:   0% (687/180213), 436.01 KiB | 397.00 KiB/s
Receiving objects:   0% (1029/180213), 548.01 KiB | 338.00 KiB/s
Receiving objects:   1% (1803/180213), 972.01 KiB | 309.00 KiB/s
Receiving objects:   1% (2091/180213), 1.11 MiB | 309.00 KiB/s
Receiving objects:   2% (3605/180213), 1.82 MiB | 214.00 KiB/s
fatal: protocol error: bad line length character: O20000 KiB/s
fatal: pack has bad object at offset 2776352: inflate returned -5
fatal: index-pack failed
error: RPC failed; curl 56 Malformed encoding found in chunked-encoding

P.S. We trust proxy root certificate in the system, also tried to add
in config but no luck

RE: Git via MITM transparent proxy with HTTPS Interception

[Jason Pyeron]

> From: Vitaly VS
> Sent: Tuesday, April 13, 2021 8:08 AM
> 
> Hello! Can a Git client work properly through a MITM transparent proxy
> with HTTPS interception?

Yes, we do it all the time.

> 
> Is there any documentation or recommendations on how to configure a
> MITM proxy with HTTPS interception for the Git work?
> 

Not that I am aware of. It is not a Git issue per se. The WAF or Proxy should not (appear) to alter any of the contents of the stream (when allowed).

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

It is likely off-topic, but what is your proxy configuration? I have personally used Git through Apache and F5 MITM proxies.

> git clone https://github.com/aaptel/wireshark.git
> Cloning into 'wireshark'...
> remote: Enumerating objects: 524729, done.
> fatal: protocol error: bad line length character: ??:s00 KiB/s
> error: inflate: data stream error (invalid literal/lengths set)
> fatal: pack has bad object at offset 2093488: inflate returned -3
> fatal: index-pack failed

Enable git and curl tracing, contact your proxy team and ask for packet capture with decryption.

> 
> git clone https://github.com/aaptel/wireshark.git
> Cloning into 'wireshark'...
> remote: Enumerating objects: 524729, done.
> fatal: protocol error: bad line length character: ????06 MiB/s
> error: inflate: data stream error (incorrect data check)
> fatal: pack has bad object at offset 17119052: inflate returned -3
> fatal: index-pack failed
> 
> 
> git clone https://github.com/aaptel/wireshark.git
> Cloning into 'wireshark'...
> remote: Enumerating objects: 524729, done.
> error: RPC failed; curl 56 Malformed encoding found in chunked-encoding
> fatal: the remote end hung up unexpectedly
> fatal: early EOF
> fatal: index-pack failed
> 
> git clone https://github.com/Homebrew/brew.git
> Cloning into 'brew'...
> remote: Enumerating objects: 148, done.
> remote: Counting objects: 100% (148/148), done.
> remote: Compressing objects: 100% (80/80), done.
> Receiving objects:   3% (6247/180213), 2.64 MiB | 1005.00 KiB/s
> Receiving objects:   4% (8247/180213), 3.75 MiB | 1.00 MiB/s
> Receiving objects:   5% (9011/180213), 4.47 MiB | 1.05 MiB/s
> fatal: protocol error: bad line length character: ?V?V7 MiB/s
> error: inflate: data stream error (incorrect data check)
> fatal: pack has bad object at offset 6558416: inflate returned -3
> fatal: index-pack failed
> error: RPC failed; curl 56 Malformed encoding found in chunked-encoding
> 
> git clone https://github.com/Homebrew/brew.git
> Cloning into 'brew'...
> remote: Enumerating objects: 148, done.
> remote: Counting objects: 100% (148/148), done.
> remote: Compressing objects: 100% (80/80), done.
> Receiving objects:   0% (1/180213)
> Receiving objects:   0% (687/180213), 436.01 KiB | 397.00 KiB/s
> Receiving objects:   0% (1029/180213), 548.01 KiB | 338.00 KiB/s
> Receiving objects:   1% (1803/180213), 972.01 KiB | 309.00 KiB/s
> Receiving objects:   1% (2091/180213), 1.11 MiB | 309.00 KiB/s
> Receiving objects:   2% (3605/180213), 1.82 MiB | 214.00 KiB/s
> fatal: protocol error: bad line length character: O20000 KiB/s
> fatal: pack has bad object at offset 2776352: inflate returned -5
> fatal: index-pack failed
> error: RPC failed; curl 56 Malformed encoding found in chunked-encoding
> 
> P.S. We trust proxy root certificate in the system, also tried to add
> in config but no luck

That is assumed, otherwise you would not have started transferring any data.

[I set the reply to header, don’t email me directly I am on the list]

--
Jason Pyeron  | Architect
Contractor    |
PD Inc        |
10 w 24th St  |
Baltimore, MD |

.mil: jason.j.pyeron.ctr@mail.mil
.com: jpyeron@pdinc.us
tel : 202-741-9397

Re: Git via MITM transparent proxy with HTTPS Interception

[brian m. carlson]

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

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

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

Re: Git via MITM transparent proxy with HTTPS Interception

[Vitaly VS]

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

Re: Git via MITM transparent proxy with HTTPS Interception

[brian m. carlson]

[-- 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 --]

RE: Git via MITM transparent proxy with HTTPS Interception

[Jason Pyeron]

> From: brian m. Carlson
> Sent: Wednesday, April 14, 2021 7:49 AM
> 
> 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.
> 

This is a non-supported use case for Git. That being said - you are going to have to trace out the communications. This is going to start with GIT_TRACE=true GIT_CURL_VERBOSE=1 on your command.

You are going to need to invest in the time and knowledge to identify why your Cisco WSA is modifying data.

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

While I agree, I work in environments where I do not have the luxury to change their minds. As a result I sometimes have to develop (very expensive use of time) test suites to tease out the secret sauce of security appliances. Sometimes we are fortunate that there is enough money to get the vendor to care and share.

You are more likely to be able to setup a local git mirror, within your security perimeter and enforce a review (think peer review software) of outbound pushes on a non-MITM connection between those two points only. Security management are much more likely to approve this bypassing your security appliance.

[I set the reply to header, don’t email me directly I am on the list]

--
Jason Pyeron  | Architect
PD Inc        |
10 w 24th St  |
Baltimore, MD |
 
.mil: jason.j.pyeron.ctr@mail.mil
.com: jpyeron@pdinc.us
tel : 202-741-9397

Re: Git via MITM transparent proxy with HTTPS Interception

[Vitaly VS]

Thanks for your answers and recommendations!

I totally agree that https interception is a bad idea, but we can't
get away from it.

We have been living with this problem for about 1.5 years. It gets
worse every month. We have reached the boiling point and want to solve
the problem without turning off https interception.


> You are more likely to be able to setup a local git mirror, within your security perimeter and enforce a review (think peer review software) of outbound pushes on a non-MITM connection between those two points only. Security management are much more likely to approve this bypassing your security appliance.

We have a local mirror(artifactory) inside the security perimeter, but
it's impossible for us to download tons of terabytes from GitHub...


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

> This is a non-supported use case for Git. That being said - you are going to have to trace out the communications. This is going to start with GIT_TRACE = true GIT_CURL_VERBOSE = 1 on your command.

> You are going to need to invest in the time and knowledge to identify why your Cisco WSA is modifying data.

Think it is. We think this is a bug on Cisco WSA that in some cases
traffic may change. Let's look at the decrypted traffic.

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

Hmmm, is there already such a list in the Git FAQ?


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

Good idea, it might be. Thank you, we will look in this direction.

ср, 14 апр. 2021 г. в 15:29, Jason Pyeron <jpyeron@pdinc.us>:

>
> > From: brian m. Carlson
> > Sent: Wednesday, April 14, 2021 7:49 AM
> >
> > 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.
> >
>
> This is a non-supported use case for Git. That being said - you are going to have to trace out the communications. This is going to start with GIT_TRACE=true GIT_CURL_VERBOSE=1 on your command.
>
> You are going to need to invest in the time and knowledge to identify why your Cisco WSA is modifying data.
>
> > > 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.
>
> While I agree, I work in environments where I do not have the luxury to change their minds. As a result I sometimes have to develop (very expensive use of time) test suites to tease out the secret sauce of security appliances. Sometimes we are fortunate that there is enough money to get the vendor to care and share.
>
> You are more likely to be able to setup a local git mirror, within your security perimeter and enforce a review (think peer review software) of outbound pushes on a non-MITM connection between those two points only. Security management are much more likely to approve this bypassing your security appliance.
>
> [I set the reply to header, don’t email me directly I am on the list]
>
> --
> Jason Pyeron  | Architect
> PD Inc        |
> 10 w 24th St  |
> Baltimore, MD |
>
> .mil: jason.j.pyeron.ctr@mail.mil
> .com: jpyeron@pdinc.us
> tel : 202-741-9397
>
>
>
>