Node: Discussion: OpenSSL 1.1.0 planning

[rvagg]

The first Alpha of OpenSSL 1.1.0 is out now so we could be experimenting with integration on a dedicated branch if someone dares to make a start.

The current list of changes is here: https://www.openssl.org/news/openssl-1.1.0-notes.html

It looks like there's some nice cleanup going on with some needed removals, there's also some interesting additions that are worth discussing (also, no header symlinking!).

The planned timing for 1.1.0 is here. The awkward part is that it's not due to be final until late April, the date roughly coincides with a projected V8 5.0 release (rough but educated guess on my part) but falls later than what would be ideal for inclusion in Node.js v6 which will go on to be LTS. I doubt it's something we can include in a semver-minor so it has to be in v6 or not from the beginning. There's some discussion going on regarding V8 and Node.js v6 timing over at https://github.com/nodejs/LTS/issues/62 that's relevant to this.

Regarding OpenSSL support, we'd be covered by their support schedule if we opted to stay with OpenSSL 1.0.2 as it's not due to be phased out until the end of 2019 and Node.js v6 LTS would end support in April 2019.

Aside from questions of timing, the following questions stand out to me as worthy of discussion:

• If we shipped a Node.js v6 without _extended master secret_ support, will we be regretting it shortly thereafter, perhaps this will become a must-have for TLS soon?
• Does the addition of CCM and/or OCB mode mean we may need new core APIs to expose the functionality or does it fit in to what we have?
• Is the asynchronous functionality useful for us at all, can we use it to retire some of our own code?

/cc @nodejs/crypto @nodejs/lts

[indutny]

ChaCha!

[indutny]

Answering to your questions:

• IMO, we should not regret it. It seems to be safer to go without it
• It will be clear later, when we will start working on this, but I think it probably add new APIs
• What do you mean? We already use cert callback in place of our old code...

[jasnell]

Overall, I'd say that this is a better justification for postponing v6 just a bit to get this landed than the possibility of a V8 upgrade. If we can get this in without the schedule slipping past the first week of May, then I'd say let's do it.

[shigeki]

I had some time to look around the features of openssl-1.1.0 today and can answer some of questions.

• extended master secret (RFC7627):
  This feature is for against to the triple handshake attack pointed out in https://www.secure-resumption.com/. There described two attack scenarios, one is renegotiation with client auth and the other is channel id with tls-unique.
  The latter does not affect Node since it is not supported. I'm not confident that the former is safe for Node. We do not check the certificate change after renegotiation as Chrome does in https://chromium.googlesource.com/chromium/src.git/+/master/net/socket/ssl_client_socket_openssl.cc#1924 . But I think It is very complicated attack so its severity seems to be low.
  The extended master secret has already been enabled in Chrome stable and it just began to be enabled in Firefox. Unless a new attack comes out, I think we need not to be in a hurry to support it.
• OCB and ChaCha20-Poly1305:
  Using AES-OCB with openssl api is nearly the same as that of AES-GCM so that I think we will need not change the crypto API. AES-CCM has a difference as discussed in #2383.
  In TLS, we cannot use AES-OCB yet while ChaCha20-Poly1305 has already had pre-assigned cipher suites and can be used in 1.1.0-alpha. ChaCha20-Poly1305 is to be included as MIT ciphers in the forthcoming TLS1.3 so I think it is worth while to test it.
• ASYNC_JOB in libcrypto:
  It seems to be a something like uv_queue_work to use crypto features in openssl. I'm not sure it has a benefit to use it in Node instead of libuv.

The API and ABI compatibilities between 1.1.0-pre and 1.0.2e are very low as shown in http://abi-laboratory.pro/tracker/objects_report/openssl/1.0.2e/1.1.0-pre1/report.html . The deployment of openssl-1.1.0 in OS distributions will be slow. As in #2783, those who is using shared openssl library bundled in OS would want to stick 1.0.2 even in the next LTS. We should discuss the timing to upgrade when 1.1.0 nearly comes to be official release.

[jbergstroem]

@shigeki that (shared library upstream support) would be a perfect discussion for the build group to have with upstream packagers. I'll try to get that mail going during holidays.

[shigeki]

@jbergstroem That's good to know that. Another concern about shared library is that we would have an issue if we applied a floating patch to openssl that leads inconsistent behavior. It should be minimum but we did it before for an unavoidable reason as in #923.

[jbergstroem]

@shigeki then upstream will at least know why if/why it fails. In general, I think most of us agree that the less floating patches we have the better :)

[rvagg]

CTC meeting discussion roughly concluded that we _should not_ hold up v6 for the OpenSSL upgrade and upgrading to 1.1.0 so soon after its release would require someone making a very good case for doing so. There doesn't appear to be a strong appetite for going ahead with this upgrade with any haste given the amount of API breakage for the little feature gain. The incompatibilities caused with distribution versions is also a factor in the negative for this.

I suggest we leave this issue open for discussion because we'll upgrade eventually.

[Fishrock123]

What's the status of this?

[rvagg]

Given that:

Version 1.1.0 will be supported until 2018-04-30.
Version 1.0.2 will be supported until 2019-12-31 (LTS).

I think we're just going to continue kicking this can down the road. It's more of a thing that we should probably _experiment_ with rather than actually ship any time soon. There may be Linux distros out there that end up shipping with 1.1.0 and it'd be good to know what kind of hoops we need to jump through to get that working.

[kroeckx]

As the Debian maintainer of openssl I will be moving to 1.1.0 soon after it's released, which shouldn't take long anymore.

[bricss]

OpenSSL v1.1.0 officially landed -> https://www.openssl.org/news/openssl-1.1.0-notes.html

[indutny]

Did it?

[indutny]

Looks like it did! Let's update :) It has a fix for TLS session cache that we have here.

[kroeckx]

So will you need any help with this?

[indutny]

@kroeckx at this point it is hard to tell. I suppose there may be some difficulties with regards to our use of some now-private fields.

[kroeckx]

It's just that nodejs is in my list of packages to get fixed.
Most of this is really trivial to get fixed. If someone else
wants to fix it, it just means I can look at other things.

[indutny]

@kroeckx oh, we'd appreciate your help and contributions on this! Please let me know if I can help you! 😉

[bnoordhuis]

We had a lot of complaints from people that link against the system openssl when we upgraded from 1.0.1 to 1.0.2 (because their copy of openssl was at 1.0.1 and it broke their builds.) I don't think that is a reason not to upgrade but some fallout and griping should be expected.

We could do it for v7 but what is the plan for v6 LTS? Support-wise we're good with 1.0.2 but I bet the addition of chacha20-poly1305 is going to make a lot of people happy. I know it's been discussed some but I'm curious if perhaps people changed their minds in the mean time.

[kroeckx]

I understand that you make binary releases that include
openssl binaries. Note that the plan is just to make it able to
build with the 1.1.0 version, that doesn't mean you should
change your distributed files to 1.0.2, but you could. The
ChaCha20-Poly1305 support can clearly be a motivation.

I'm not sure what broke when going from 1.0.1 to 1.0.2. They
really should have been compatible. The only thing I can imagine
is that it was build against a 1.0.2 version but they tried to run
it with a 1.0.1 version, you added support for some new functions
in 1.0.2 and their binaries didn't have those new functions.

With 1.1.0 the soname changed, and I think for windows the name of
the DLLs changed. That would mean that if it was build against
1.1.0 and they still had some 1.0.X version, but not the new
files, that they'd get an error that the library wasn't found
instead.

But I think it's kind of problematic they might not get new
openssl version.

Kurt

[AaronHarris]

As someone who was affected by builds not working when Node upgraded to OpenSSL 1.0.2, I can say that building on OpenSSL 1.1.0 will make things equally as broken, in a good way - relying on the system OpenSSL was generally not a good idea, and now that people have (hopefully) fixed their builds, moving to OpenSSL 1.1.0 should be not much different from the changes people had to make when moving to 1.0.2.

[kroeckx]

I created pull request #8491 for this.

[bricss]

OpenSSL 1.1.0a unveiled -> https://www.openssl.org/news/openssl-1.1.0-notes.html

[ncopa]

I believe that when major distros ships openssl-1.1.0 then will people who uses the official node binary with bundled openssl have problems with 3rd party modules that uses the system openssl.

[jasnell]

Ping. @nodejs/crypto @nodejs/ctc ... given that we're a week out from the v7 release, it doesn't look like this is going to happen for v7. I'm removing it from the v7 milestone and putting it onto v8.

[rvagg]

fwiw if this can be done in a backward compatible way (I suspect it can be, the "enable build with shared openssl 1.1.0" anyway) then it could land in 7.x if it's ready. That would be pretty neat and set us up nicely for Linux distros that start migrating to primarily use 1.1.0 (although I'm not sure if there are any plans on that front yet).

[vielmetti]

As a point of interest, the Alpine Linux system is moving over to libressl right now in their "edge" builds targeting their 3.5 release. I mention this because Alpine is a popular base image for Docker environments.

[kroeckx]

On Wed, Oct 19, 2016 at 05:21:48AM -0700, Rod Vagg wrote:

fwiw if this can be done in a backward compatible way (I suspect it can be, the "enable build with shared openssl 1.1.0" anyway) then it could land in 7.x if it's ready. That would be pretty neat and set us up nicely for Linux distros that start migrating to primarily use 1.1.0 (although I'm not sure if there are any plans on that front yet).

The patch supports both 1.0.x and 1.1.0.

Kurt

[sgallagher]

fwiw if this can be done in a backward compatible way (I suspect it can be, the "enable build with shared openssl 1.1.0" anyway) then it could land in 7.x if it's ready. That would be pretty neat and set us up nicely for Linux distros that start migrating to primarily use 1.1.0 (although I'm not sure if there are any plans on that front yet).

I should point out that Fedora 26 uses OpenSSL 1.1.0 (though for the moment we have a compatibility package for projects that are stuck on 1.0.2). Just thought that might be relevant information. Of course Fedora is also blocked on https://github.com/nodejs/node/issues/10388 as well.

[sgallagher]

What are the plans for adding OpenSSL 1.1.x support to Node.js? Is there a plan to also backport support to 6.x LTS or will that remain on 1.0.x indefinitely?

[richardlau]

@sgallagher See the discussion in https://github.com/nodejs/node/pull/11828

[dylancarlson]

The lack of flexible support for different OpenSSL versions (as well as LibreSSL) is just going to get more painful. Chrome/Chromium now have a hard dependency on nodejs to build, so even for people who have no intention of running nodejs, it is getting incorporated into things which is making this particular issue more problematic.

[danbev]

The lack of flexible support for different OpenSSL versions (as well as LibreSSL) is just going to get more painful.

I'd really like to see support for different version of OpenSSL too as it would simplify things at work for me. It would also be nice to support LibreSSL or BoringSSL or whatever comes along in the future. I've only just started to look closer at the crypto code but I'd be happy to work on this and see what can be done.

[jasnell]

Taking this off the 8.0.0 milestone

[janflyborg]

I am just wondering what the status of this is. Are there planned support for OpenSSL 1.1 in node.js 9 or 10?

Our company have a number of resource constrained IoT devices that would benefit of being able to communicate with our node.js backend with ChaCha20 and Poly1305. Can we help in any way?

[joyeecheung]

@janflyborg There is still FIPS support that needs to be figured out. See https://github.com/nodejs/TSC/pull/387/files

[TBK]

@danbev There is a Gentoo effort to provide a node build with Libressl thought it might be of interest (see files dir) - https://github.com/gentoo/libressl/tree/master/net-libs/nodejs

[rvagg]

A lot of extra discussion on this has moved to https://github.com/nodejs/node/pull/16130

Summary is: you can now compile against 1.1.0 and it works great, we're even testing it in CI for every new commit on 8,9,10 (I may be wrong on 8, don't have it in front of me). Unfortunately 1.1.0 isn't a long-term supported release line from OpenSSL and we're still waiting to hear what the next one will be after 1.0.2. 1.1.0 ends official support in August of 2018 while 1.0.2 goes on until the end of 2019. Until we have a stable roadmap from them we're going to have to pin to 1.0.2 but we're happy to enable the option of compiling against 1.1.0 and future versions given help from the community.

Also worth noting, as @joyeecheung was pointing out, we have no FIPS other than 1.0.2, they're not even planning on a new FIPS module until after 1.1.1! Given that, my guess is that it's going to be 1.1.2 that'll be the next major release we want to care about .. which leaves us in an awkward position for Node 10 so we'd better figure this out soon ..

[mhdawson]

@rvagg have we reached out to the openssl team? I think we should try to talk to them directly to ask what they recommend given the position we are in.

[kroeckx]

We currently don't know yet when to announce the next LTS release,
and which version it's going to be. According to our release
strategy we should announce a new LTS this year, and so it'll be a
release we make this year. This could be the upcomming 1.1.1, or
even a higher number (1.2.0, 1.1.2). We at least want to make this
API compatible to 1.1.0, not sure if it's going to be ABI
compatible.

TLS 1.3 will be supported in 1.1.1. So if you think this is an
important feature you might want to think about 1.1.x

[rvagg]

Thanks @kroeckx. Since we need to lock in on a version for Node 10 soon, which will become LTS, we may need to pick a >= 1.1.0 OpenSSL for that and make it known that Node 10 may include an upgrade to an LTS OpenSSL during its cycle (and cross our fingers on ABI compatibility I suppose). Otherwise we're going to be stuck with 1.0.2 until April 2021 in Node 10. Again though, FIPS is going to be a big problem for Node 10 but we may just have to make it clear that Node 10 doesn't have FIPS support until/unless we get it upstream.

I'll kick off that discussion with nodejs/release with an initial proposal soon.