Repository navigation
Discussion: OpenSSL 1.1.0 planning #4270
Description
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 nodejs/Release#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
Activity
indutny commentedon Dec 14, 2015
ChaCha!
indutny commentedon Dec 14, 2015
Answering to your questions:
jasnell commentedon Dec 14, 2015
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 commentedon Dec 16, 2015
I had some time to look around the features of openssl-1.1.0 today and can answer some of questions.
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.
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 crypto: API changes needed for AES Counter with CBC-MAC (CCM) support #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.
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 commentedon Dec 16, 2015
@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 commentedon Dec 16, 2015
@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 commentedon Dec 16, 2015
@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 commentedon Dec 23, 2015
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 commentedon May 31, 2016
What's the status of this?
rvagg commentedon May 31, 2016
Given that:
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.
60 remaining items
deps: add s390 asm rules for OpenSSL-1.1.1
deps: add s390 asm rules for OpenSSL-1.1.1
OpenSSL 1.1.1 support
OpenSSL 1.1.1 support
deps: add s390 asm rules for OpenSSL-1.1.0
deps: upgrade openssl sources to 1.1.0h