[ale] Decrypting SSL traffic at the client side

[Dylan Northrup]

I'm trying to debug some LB/proxy related issues retrieving git
repositories (more details below for those interested).  The NetEng folks
are stonewalling because "we're just layer 3; obviously client problem"
and, since the traffic is HTTPS, I can't view the HTTP protocol level
per-packet headers to provide evidence to the contrary.

Given the following, is there any way to get a clear text packet capture of
the traffic?
- I have root on the box
- I am invoking the commands (in this case `git` and `curl`)
- I do not have access to any network equipment
- I do not have access to the git server (go.googlesource.com for golang
dependencies)

Full details:
My host is an Ubuntu 14.04.5 LTS VM.
Network path A for outbound traffic goes through an outbound NAT, to a load
balancer, then to one of two McAfee Web Gateway hosts, then out to the
Internet.  Network path B skips the load balancer and goes straight from
the NAT to the MWG hosts and out to the internet.

The failure manifests in the following conditions:
- using Network path A (using the load balancer)
- retrieving a large repository such that the request is larger than git's
http.postBuffer

In these conditions, the `git clone` operations fail a significant portion
of the time (with a failure rate between 60-90%).  If we use Network path B
(and no other changes) success rate is 100%.  If I increase the
`http.postBuffer` size to some arbitrarily large value (and no other
changes, success rate is 100%.

Traffic is large enough to trigger `Transfer-Encoding: chunked` and is
compressed with gzip by the end servers.  I know there's some wonky
interaction between the LB and the web proxy, but since I don't control
either of those pieces of gear, I'm stuck unless I can see the raw HTTP
traffic.  I have run `git` with `GIT_CURL_VERBOSE=1 GIT_TRACE=1 git clone
URL` but the headers I see there aren't showing me the right bit of info.

Any suggestions would be much appreciated!

-- 
Dylan Northrup
"Adversity is just change we haven't adapted ourselves to yet."
  - Aimee Mullins
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.ale.org/pipermail/ale/attachments/20190123/45dfbecb/attachment.html>