Hacker News Reader

Comment by paulddraper | Hacker News Reader

I see a lot of hate for TLS interception of any kind, but I did it just the other day for my CI servers. This isn't what Chrome and Mozilla are upset about, but it's an example of IMO valid TLS MITM.

Our multi-language build process downloads from Bintray, Maven, npm, Github, Cloudfront, S3 using curl, Maven, SBT, npm, apt, etc. To improve times and insulate against downtime, I MITM the CI servers with a caching proxy.

Two environment variables (http_proxy, https_proxy), and everything is cached, fast, and reliable.

View on HN

There is no valid TLS MITM. All attempts at TLS MITM break TLS in some way -- very commonly with TLS client certificates.

Edit: You're only proxying the encrypted data and not trying to do a MITM, so this doesn't break TLS, but it doesn't do a MITM. I added this complaint as a more general statement at the top-level of comments.

It's my network with my assets and my data. Only I decide what is valid wrt to TLS on my network. The number of applications that purport to service a particular purpose but then proceed to exfiltrate substantial amounts of data that is not even tenuously related to the purpose of the application has destroyed any good will on my part.

On my network there are an order of magnitude more valid TLS MITMs happening than there are valid non-MITMed TLS connections.

Just setting https_proxy isn't going to give you any caching benefits for https requests and isn't going to MITM TLS in any way. The client will make a CONNECT request through to the destination and the encryption is end to end and the response not cacheable by the proxy.

Point https_proxy to a CONNECT-aware HTTPS MITM proxy, and it does.

What you did doesn't sound like MITM/TLS interception.

Assuming you meant you set those environment variables for your applications, then that wasn't mitm. It was application-level supported proxying.

Those are totally different things.

I apparently was unclear.

I set up a caching MITM TLS proxy (with a trusted cert on my CI server).

Why would you even need that? If you have `https_proxy=http://caching-proxy.local` with `http://` rather than `https:`, the client will use HTTP to connect to the proxy, and the proxy will connect to the destination using HTTPS. Since the client itself does not do any TLS, you don't need any CA cert shenanigans in this setup, and you can still intercept all the traffic on the proxy.

(Of course, this means that traffic between the client and the proxy is unencrypted, so if you do not trust that network, you will need to add a VPN or similar there.)

It would be very convenient if it worked that way, but it doesn't.

    $ https_proxy=http://localhost:8888 curl -vo /dev/null https://example.org
    *   Trying 127.0.0.1...
    * Connected to localhost (127.0.0.1) port 8888 (#0)
    * Establish HTTP proxy tunnel to example.org:443
    > CONNECT example.org:443 HTTP/1.1
    > Host: example.org:443
    > User-Agent: curl/7.35.0
    > Proxy-Connection: Keep-Alive
    > 
    < HTTP/1.0 200 Connection established
    < Proxy-agent: tinyproxy/1.8.3
    * Proxy replied OK to CONNECT request
    * successfully set certificate verify locations:
    *   CAfile: none
      CApath: /etc/ssl/certs
    ...
    * Server certificate:
    *    subject: C=US; ST=California; L=Los Angeles; O=Internet Corporation for Assigned Names and Numbers; OU=Technology; CN=www.example.org
    *    start date: 2015-11-03 00:00:00 GMT
    *    expire date: 2018-11-28 12:00:00 GMT
    *    subjectAltName: example.org matched
    *    issuer: C=US; O=DigiCert Inc; OU=www.digicert.com; CN=DigiCert SHA2 High Assurance Server CA
    *    SSL certificate verify ok.
    ...

The protocol defined in https_proxy is irrelevant. CONNECT will be used, with a TLS tunnel.

That's odd. I use mitmproxy at work to check how my apps call REST APIs on HTTPS endpoints, and I definitely don't have mitmproxy's interception CA installed.

It's not MITM. It's regular HTTPS tunneling through a regular proxy, which is a feature supported by most proxies. Both the client and the proxy must be configured and aware of each other.

Have you tried Sonatype Nexus OSS yet? It's free (actually, open-source-free) and supported by docker, npm and maven. No need for strange SSL interception any more.

(Not affiliated, just an extremely happy user)

Yep, I've used it.

I have to make sure each of the tools is setup to use it, and I have to move the source repos from code to Nexus config, and it doesn't help if anyone does something non-standard, e.g. last I checked installing Angular involved an ad-hoc Github download.

HTTPS_PROXY gets virtually everything in one go.

Reply on news.ycombinator.com