Repository navigation
TLS secure context not honored after upgrade from v9.11.1 or v8.10.0 to v10 #20833
Description
tls.connect({
host: 'catalogue.swanngalleries.com',
port: 443,
ciphers: 'DES-CBC3-SHA',
secureProtocol: "TLSv1_method"
}, () => {
console.log('SUCCESS')
}).on('error', function (err) {
console.log('ERROR')
})The code above attempts to connects to a web site that is very out of date for its TLS version (but "real world"), it works on v9.11.1 or v8.10.0, but fail on all v10 version v10.0.0 v10.1.0. Providing the context as a separate object does not help , it fails in the same way.
Activity
ryzokuken commentedon May 21, 2018
/cc @nodejs/crypto
ryzokuken commentedon May 21, 2018
I can confirm that this prints out "SUCCESS" in Node 8 while printing out "ERROR" in Node 10
ryzokuken commentedon May 21, 2018
Couldn't find anything relevant in the "changes" block at https://nodejs.org/api/tls.html#tls_tls_connect_options_callback, so probably no
semver-majorsryzokuken commentedon May 21, 2018
Okay, so removing the
ciphers: 'DES-CBC3-SHA'part breaks it on Node 8 at well, maybe Node 10 isn't respecting this particular value?Example:
apapirovski commentedon May 21, 2018
We upgraded OpenSSL and deprecated (/removed) a bunch of stuff in crypto for 10.0.0, seems like the most likely culprit.
ryzokuken commentedon May 21, 2018
@apapirovski exactly. Looking at https://www.openssl.org/docs/man1.1.0/apps/ciphers.html#CIPHER-LIST-FORMAT,
DES-CBC3-SHAisn't the best cipher to use anyway, so they're probably out of luck.ryzokuken commentedon May 21, 2018
Okay, a few observations:
CBCshould be affected.alaindemour commentedon May 21, 2018
This site(which I am not affiliated with) and that I just gave as an example is clearly not doing a great job at keeping an up-to-date TLS profile, but as a client a node v10 program should be able to connect to it as version 8 or 9 could. All the browsers I tried can also do it i.e. chrome/firefox/safari etc ...
alaindemour commentedon May 21, 2018
What I mean is that for a server, it seems reasonable to tighten up node security, but as a client it would seem reasonable to be able to connect to any site that a mainstream browser can connect to.
ryzokuken commentedon May 21, 2018
But again, if clients don't deprecate old/crufty ciphers, servers will keep using them. They won't have any incentive to upgrade.
ryzokuken commentedon May 21, 2018
@apapirovski Maybe you meant #19794?
apapirovski commentedon May 22, 2018
I think DES might no longer be supported in OpenSSL 1.1.0 based on some research. That said I'll let @nodejs/crypto speak to whether that's what's going on here.
ryzokuken commentedon May 22, 2018
@apapirovski I believe
DES-CBC3-SHAis not a DES cipher but a 3DES cipher instead.ryzokuken commentedon May 22, 2018
@alaindemour okay, I haven't spent a lot of time researching this, but the more I read, the more I think you shouldn't use
DES-CBC3-SHA. It is very insecure, from what I can see.It's vulnerable to the SSL POODLE attack as I mentioned earlier. Read: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-8730
It's also vulnerable to a birthday attack called "SWEET32", which is kinda alarming, and you probably shouldn't use it at this point. Read: https://sweet32.info/ and https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-2183 and https://www.openssl.org/blog/blog/2016/08/24/sweet32/
It's probably affected by even more attacks, for a more detailed summary, check this: https://www.gracefulsecurity.com/tls-ssl-vulnerabilities/
bnoordhuis commentedon May 22, 2018
That's correct and, since this is not something we're going back on, I'll close out the issue. @ryzokuken amply documented why you shouldn't be using it anymore.
alaindemour commentedon May 23, 2018
The overall approach (forcing deprecation of the TLS options way before common browsers do) means one cannot wrote a web crawler using node.js any more, a web crawler has to connect to whatever site is out there on the internet regardless of how badly configured there are (if they are used by human beings), it is not a "choice" of the developer to use this cipher or that cipher one has to use whatever the site actually mandate. This is essentially saying "web crawlers are not a good use case for node". Is it a tenable position?
bnoordhuis commentedon May 23, 2018
Node.js aims to be secure by default. Nothing and no one is stopping you from building Node.js from source in a configuration that enables SSLv3 or insecure ciphers again, but it's not something we do - or will do - in release builds.
ryzokuken commentedon May 23, 2018
@alaindemour it's not, because:
Browsers could keep supporting
<blink>for all we know, I don't think following "major browsers" or any browsers, in that regard is a priority for the project.If a website uses a cipher that was, and I quote, "prohibited from being used" over 3 years ago by the IETF itself, has vulnerabilities that are easily exploitable in ways known to the general public, I don't think we should support it TBH.
I don't think it's our problem if they haven't updated their website even after so many years of the deprecation. I mean, there's a reason things are deprecated, right? I don't think it would have taken them a lot of time to upgrade, and if a team cares so little about the security of their website and users, then they kinda bring this upon themselves, don't you think? This is straight out negligence on their part.
We definitely won't hamper the security of thousands of projects running Node.js and affect our security release cycle because of a single website that fails to upgrade to modern, secure ciphers.
rvagg commentedon May 23, 2018
I'll second @bnoordhuis here: we're moving forward with secure-by-default, we now have OpenSSL 1.1.0 and will soon have 1.1.1 in Node 10+. We've been fairly aggressive in deprecating and removing broken cipher and protocol support from default builds. But you still have the option of building Node yourself to make it insecure-by-default if that's your use case. It's just not something we can afford to do for the broader user-base which expect a higher standard from Node.js.
Moving forward I think we're going to see a pretty strong push toward AEAD ciphers thanks to the big jump in restrictions in TLS 1.3 (and therefore HTTP/2). 1.1.1 will give us TLS 1.3 and I imagine there to be a strong encouragement across the board to migrate for servers given that clients (browsers) are moving quickly on this.
(@ryzokuken thanks for your comment on the YouTube feed for the TSC meeting, I hadn't seen this discussion prior, I hope this answers your question)
alaindemour commentedon May 31, 2018
I actually rewrote all my client code using Chrome Headless which seems to behave correctly when you pass the right TLS options. I understand that the community is probably stretched and does not want to go back on a major code surgery that probably involved tons of work, and this is not a mainstream use case for node, but it seems that this is really a product management decision happening as unintended consequences . Essentially this is saying one cannot and should not rely on node.js to write real world CLIENT applications , it puts node on a trajectory to become a niche platform only good enough to write certain classes of http servers. Note that this is something you can do reliably in just about any platform (JVM ecosystem, Golang, .NET ecosystem, C etc.) but not in node any more. It also probably means that to be consistent with this "point of view", there may be some other security related options in the node.js HTTPS client that should be depracted as they cannot be guaranteed to work in the future (i.e. for instance the TLS connection option "rejectUnauthorized: false" that let TLS connection happen with a bad certificate, which is also super useful because many real world sites have problematic certificates, but clearly will produce "unsafe" code
ryzokuken commentedon May 31, 2018
If I understand you correctly (correct me if I don't), you're warranting for us to make core a tad less secure just because there's a "real world site" that doesn't conform to modern standards. I'm sorry to say that that would likely not happen. Yes, we're spread too thin, but I don't believe it would get reverted even if we weren't, because getting less secure moving forwards is counterintuitive and something we don't plan on doing.
Keep in mind, there will always be code in the wild that would work with outdated ciphers and other sorts of crazy stuff. Supporting them is not our job. It's not our fault that someone else doesn't care about their users' privacy, and tbh their users should probably use a different provider.
Care tell me what you think about https://www.blog.google/topics/safety-security/say-yes-https-chrome-secures-web-one-site-time/? Chrome will soon (if it doesn't already) block any non HTTPS websites, isn't that a welcome step according to you?
apapirovski commentedon May 31, 2018
Node 8 is going to be actively supported until April 2019 and doesn't go EOL until after Oct 2019. If the site in question doesn't upgrade by then, I'm not sure that's something Node is obligated to support. There's nothing wrong with using Node 8 if this is functionality you need.
ryzokuken commentedon May 31, 2018
Yeah, more importantly, that too. It's not that we've dropped support for Node 8, so you can still run that insecure code in Node 8 if you can and it'll work until April 2019. That said, I still won't suggest doing that, though.
alaindemour commentedon Jun 22, 2018
my application is a crawler, do you think the google crawler refuses to crawl sites because they are poorly constructed or use obsolete tech? no, they find a way to crawl any site if it have legit/relevant data (like the one I gave as example). But as I said I moved all crawler code to Chrome Headless which works very well for this use case, so all is good.
ryzokuken commentedon Jun 22, 2018
@alaindemour Great! I'm glad you were able to find a replacement.