1. 8
  1. 1

    Well, reading this makes me very thankful that I have nobody forcing me to use a proxy of any sort. It looks like a lot of effort to maintain this, and it’s actually somewhat surprising that it is even possible with a lot of things (I don’t think too much software gets developed with using a mandatory man-in-the-middle anymore these days?)

    1. 1

      I don’t think too much software gets developed with using a mandatory man-in-the-middle anymore these days?

      You’d hope, but no. I have worked behind mandatory MITM TLS-breaking proxy in the past, and a lot of software still gets developed in such environment, and supporting such environment is basically a requirement once you get popular enough to get such users.

      1. 1

        Well it’s part of reality, even in non mega-corps. I guess every tool (or especially package manager type thing) needs to grow up at a certain point and accept this reality, sometimes the people who have to live with the fallout (behind the proxies) need to do the work :P

      2. 1

        I used to work for an ISP where even development was in machines you had to ssh into and had a proxy to the Internet, like what’s described in the article.

        I wondered what were the EXTRA_CERTS variables for. https is tunneled via CONNECT, does that mean that certificates to verify Internet Tls connections have to be provided and exposed by the sysadmin?

        The author doesn’t mention ruby, but there is a very handy function in the stdlib , URI.find_proxy , which abstracts the proxy env var discovery described in the article, that every other stdlib network library uses. Sadly, there are a bunch of non-stdlib libraries that ignore it, among them a few popular http libraries.

        1. 1

          I assume they had to add to the CA bundle for either or both of:

          • a bunch of services (e.g. caching pypi mirror) with certs signed by an internal CA because someone thought that was easier than using letsencrypt, or…
          • a proxy that MITMs all https connections (by generating its own certs on the fly from its own CA cert) and requires the client to trust the CA cert that belongs to the MTIMing proxy (¹). These are often used for “data lots prevention” proxies by big organisations. (I hate these things because they tend to be unreliable and buggy, and users report the DLP proxy’s bugs and downtime to the vendors of every SaaS product they use, rather than to the people who run the broken proxy.)

          (¹ pedantically, there might be an intermediate CA cert in between, but it doesn’t matter much.)