NTLM Proxies are the Devil’s spawn

how NTLM proxies were conceived

Even though most developer apps recognize and support proxies, they all require some sort of configuration either on the commandline, through environment vars (e.g. http_proxy) or via a configuration file. Setting up a non-encrypting proxy is tedious, but none in my experience support NTLM-based authentication. The process for getting these apps to talk across a proxied firewall is painful. So, every developer who wants their tools to access the internet needs to configure CNTLM and configure their apps to use this proxy. This is fiddly too, as some apps use HTTP_PROXY/HTTPS_PROXY environment variables, and some use a config file. This config file could be in the install directory, users home directory (%USERPROFILE%/.gitconfig), an app directory in the home directory (%USERPROFILE%/.m2/settings.xml), some other random place, or commandline (npm config set proxy..., npm config set http-proxy ..., etc.

Woe to you if the https proxy cert’s is self-signed so that the signature can’t be traced back to a standard Certificate Authority (CA). There’s a whole new ring of Hell of figuring out how to disable signature validation. Most of the time signature validation can’t be disabled, so another configuration needs to be set to tell the app to use the http flavor of a given repo instead of the default https, if it even offers a non-encrypted version.