Superagent: No way to set rejectUnauthorized option of underlying node https request

[georgesnelling]

TJ, for https requests, node core changed the default value of the https.request option rejectUnauthorized from false to true.

8.22: http://nodejs.org/docs/v0.8.22/api/https.html#https_https_request_options_callback

10.4: http://nodejs.org/docs/v0.10.4/api/https.html#https_https_request_options_callback

This means that if a node 0.8.x client sends an https request to a server with a self-signed certificate it will succeed. A node 0.10.x client sending the same request to the same server will fail with Error: DEPTH_ZERO_SELF_SIGNED_CERT.

While I agree with the change in default, we need to be able to set this bit, (similar to curl's --insecure option) in our request lib in order for our tests to hit https servers using self-signed certs. Mikeal's request lib exposes a strictSSL option which maps to the underlying node option, but I can't find a way to twiddle that bit from superagent.

I hate to clutter superagent's clean api, but perhaps an .options({}) method, passed through to node's request constructor, could give those who cared full access to all the underlying knobs. There's probably a cleaner way...

Thanks.

[georgesnelling]

That works. Closing...

[MartyGentillon]

I am inclined to think that that is a lousy solution. One of the reasons to use SSL is that you get to authenticate the server. This shuts off that authentication application wide. I am likely talking to many different HTTPS systems. Only a handfull of these uses a self signed certificate. What happens when someone tries to spoof one of the other services that I am talking to? Because I have "avoided the issue altogether" I now have a new issue, where I am vulnerable to spoofing in general.

[georgesnelling]

In general I agree with you. In our particular case it worked OK because we use server modes: dev, test, prod, and we set that flag only for dev and test. However, it is at best a blunt instrument, and in general, I think that API wrappers should expose some way to twiddle all the knobs of their underlying lower-level APIs. I don't want to reopen because we've worked around it, but feel free to reopen if it is important to you. Cheers!

[doublerebel]

I believe this is duplicate of #188 ?

[devangpaliwal]

process.env.NODE_TLS_REJECT_UNAUTHORIZED = 0; Worked!!

[mikemaccana]

Is it currently possible to pass rejectUnauthorized in options? Reading some of the linked comments suggests it is, but there's nothing mentioned in the documentation and it doesn't seem to work when I try.
For my own use case process.env.NODE_TLS_REJECT_UNAUTHORIZED = 0; is dangerous.

[kornelski]

We don't have a solution to this yet.

• The general idea is to have .tls() method with TLS-related options, but the current pull requests simply allow setting of _any_ agent option, and I'm not comfortable with having an "anything goes" unlimited API. It'd help if someone came up with a whitelist of useful options.
• rejectUnauthorized is not scary enough. It should be THIS_IS_TOTALLY_INSECURE_AND_WILL_EAT_BABIES = true or such.

[mikemaccana]

Thanks for the quick answer. Good point, node itself doesn't name the option very well, I've asked what people think about renaming it: https://github.com/nodejs/node/issues/5258

In my case (I want to check an existing TLS setup so I can recommend how to fix it) I ended up just checking for err.code === 'UNABLE_TO_VERIFY_LEAF_SIGNATURE' which was sufficient for my needs.

[harshithjv]

@devangpaliwal @mikemaccana

I am not able to make make it work by setting process.env.NODE_TLS_REJECT_UNAUTHORIZED = 0;. Where should I set it?

I am using React with Router. I tried manually setting environment variable on windows command prompt. Even that did not work.

[kornelski]

Please never use NODE_TLS_REJECT_UNAUTHORIZED for anything, ever. It's a dangerous option that ruins security of all requests made by node.

Please either get a free certificate from Letsencrypt, or create your own certificate and CA.