Can I force https requests to use http

Question

I have a situation where my employer uses a cert to spy on everyone's https traffic. They set it up poorly with a self signed certificate so unless the application allows me to ignore the cert I just get invalid cert messages.

I am trying to npm install and a script it is running is attempting to download a file via https which fails. I have tried to ignore the cert in node but no luck.

The only thing I can think of would be to force systemwide all https (or at least the one to this address) to use http instead. Kind of like if the host file was not protocol agnostic.

Is there any way we could accomplish this? I am on Win7.

Answer 1

In most cases (and also this case), this is not possible. You’ll just be redirected to HTTPS. So I won’t bother with that.

Instead, I’ll try to answer your actual question: How to get NPM to work. There is a way to use a HTTP connection:

npm config set registry http://registry.npmjs.org/

This is not a good idea, though. Just as insecure, but still using HTTPS:

npm config set strict-ssl false

Instead, consider telling NPM about your employer’s CA:

npm config set ca "-----BEGIN CERTIFICATE-----\nXXXX\nXXXX\n-----END CERTIFICATE-----"

Values should be in PEM format with newlines replaced by the string "\n".

The security of all this of course depends on your employer’s HTTPS interceptor. If it sucks, it’s all as insecure as plain HTTP.

Answer 2

You can setup your own local HTTPS proxy and have it ignore bad certificates. One easy way of doing that is with Fiddler. It has an option to ignore certificate errors. Fiddler will trust your invalid certificate and in turn provide you with a trusted certificate installed into your local certificate store.

This is obviously very dangerous and should only be done in your specific case where your workplace doesn't allow for proper certificate validation.

Answer 3

This kind of "wrapper" certificate is common in most web proxy/IDS systems. The default Windows behavior is to automatically detect proxy servers on your network (which is stupid for lots of reasons but that's beyond the scope of this discussion). All you should need to do is uncheck that option from your Internet Options control panel (connections tab, LAN settings button). Just uncheck all the boxes.

You'll note from the screenshot that this example has the settings grayed out and enforced by Group Policy. I'm assuming this computer isn't on the domain (because if it IS on the domain the proxy server is not set up correctly, which means your sysadmin is incompetent and therefore OK with training users to ignore certificate warnings).

Most applications simply accept the system's proxy settings when creating sockets. I don't know npm well enough to know if it has proxy override settings in it.

---

On a side note, "spying" is a bit of a strong word. It's a common malware tactic to use HTTPS connections to evade intrusion detection systems. If you're running a corporate network and doing your due diligence from a network security standpoint, you need to be able to inspect both HTTP and HTTPS packets.

Answer 4

What your employer is doing is common, and using a self-signed certificate for this is actually the only way, as no CA will issue a cert to an organisation that you can then use to sign other certs (if you run your own CA - e.g. AD CA services- you could have a cert issued for this, but it would still derive from the organization's root cert which will be self-signed).

Fundamentally, in order to do things like

• block https sites without a poor user experience (have the browser display a proxy block page instead of a generic browser connection failed page)
• scan downloaded content for malware (imagine if we gave up scanning downloads just because they were moved to https)
• apply URL-level control of access to https sites (e.g. block facebook except for the company page)
• prevent uploads (e.g. data leakage protection) to https sites
• cache content to reduce upstream bandwidth requirements

which are common and arguably reasonable endeavours in a business, it becomes necessary to break into the encryption of https. This is often called a Man in the middle (MitM) "attack". Even though the term "attack" is pejorative there can be arguably bona-fide reasons to do it.

In order for the proxy to be able to modify content (e.g. send block pages), it needs to be party to the crypto, this requires it to have a private key and a certificate that is used on the client-side connection. In order to minimise deployment problems, this is done with a signer certificate, which is added to client trust stores, and used to sign newly-generated certs for each site the clients connect to (typically which copy the attributes from the actual server cert to pass client validation). This way the clients only need to trust 1 cert (the one used to sign the spoofed certs).

MitM (often called SSL inspection) breaks things like:

• Extended-Validation certs (since these cannot be spoofed)
• Client certificates (sites using these won't work)
• Cert pinning. If a site uses certificate pinning, the client will reject the spoofed cert.
• Windows updates, and iTunes

For these reasons, proxies with this capability (e.g. Squid, WinGate) need to have an exclusion list feature which allows certain sites to not be intercepted.

You may be able to convince your admin to add the sites you need to this list.

Disclaimer: I work for Qbik who are the authors of WinGate.

Answer 5

I would route around that, or more specifically, use a encrypted tunnel to an outside server (I have a Raspberry Pi on my home network). I use SSH and a dynamic tunnel to get around web filtering all the time. Then configure your program to use a SOCKS proxy on localhost:####. The number is the local port the dynamic tunnel is connected to. Of course, this would probably be against your company's policy.