plans on incorporating LibreSSL
Closed this issue · 58 comments
From the 2.1.2 (2014-12-09) release notes:
- Initial support for Microsoft Windows 32-bit and 64-bit flavors has been added for mingw-w64 targets. This can be used to generate native libraries that are usable in other Windows development environments as well.
+1 for some kind of replacement. I know Google has BoringSSL in Chrome, but it doesn't seem to be a very publicized project; maybe they don't really want external dependents.
@domenic or maybe they don't care about dependents but they deem their changes to be too experimental and Chrome/Android specific [1]. I've read they do interchange code with LibreSSL and license all there stuff under ISC because of that [1][2].
[1] https://www.imperialviolet.org/2014/06/20/boringssl.html
[2] http://opensslrampage.org/post/89512434190/license-changes-in-boringssl-code
Is mingw compatible with the VS compiler/linker yet? I would think that would be a problem as long as VS is used to build iojs.
From @bcook-r7 the maintainer of libressl-portable:
... LibreSSL 2.1.2 supports building static Windows libraries. The next release will support building DLLs as well (or you can try out a snapshot here). ...
libressl/portable#59
Are they planning on supporting MSVC builds?
I like to keep the build process relatively straightforward. If it's going to involve two different compilers that's a big no-no to me.
@piscisaureus I can imagine, unfortunately it doesn't look like that's what they're planning: libressl/portable#59 (comment)
That pretty much kills it for us, doesn't it? What do we do with this issue? Close?
Aside, I looked at the libtls API when it was first announced and I doubt it would be a good fit for the tls module in io.js. The API seems to be designed for the common case; reasonable design choice but the way TLS is implemented in io.js is not the common case.
@bnoordhuis can you explain a bit what you mean with "the way TLS is implemented in io.js is not the common case"?
@timkuijsten libtls caters to synchronous socket-based TLS (at least, that's the impression I get) but the TLS layer in io.js is neither synchronous nor does it map directly to sockets. There are also a number of knobs that libtls doesn't appear to expose.
That sounds right @bnoordhuis. While there are some recent changes to make libtls support non-blocking operation as well, but this work is ongoing and not quite ready.
couldn't as a first step LibreSSL with the legacy openssl bindings be dropped in? that would give some benefits off the bat like chacha20/poly1305
in other news doesn't look like libressl has implemented the chacha20/poly1305 aead yet
Hi @calvinmetcalf - are you having trouble getting those ciphers to work with LibreSSL? I believe they are the default when using TLS 1.2, unless I have misunderstood the problem. I just checked with 'openssl s_client':
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-CHACHA20-POLY1305
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
Protocol : TLSv1.2
Cipher : ECDHE-RSA-CHACHA20-POLY1305
Yes they are both in there but I wasn't able to find the combined aead in
there, so you couldn't use it as a drop in for gcm.
On Mon, Jan 19, 2015, 5:26 AM Brent Cook notifications@github.com wrote:
Hi @calvinmetcalf https://github.com/calvinmetcalf - are you having
trouble getting those ciphers to work with LibreSSL? I believe they are the
default when using TLS 1.2, unless I have misunderstood the problem. I just
checked with 'openssl s_client':New, TLSv1/SSLv3, Cipher is ECDHE-RSA-CHACHA20-POLY1305
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
Protocol : TLSv1.2
Cipher : ECDHE-RSA-CHACHA20-POLY1305—
Reply to this email directly or view it on GitHub
#428 (comment).
More specifically, compiling node with libressl works and allows encrypting
with chacha20 but throws when you try to set an auth code, first due to a
hard coded reference in node to gcm then if that is fixed it throws in
libressl due to that api not working with chacha.
On Mon, Jan 19, 2015, 6:21 AM Calvin Metcalf calvin.metcalf@gmail.com
wrote:
Yes they are both in there but I wasn't able to find the combined aead in
there, so you couldn't use it as a drop in for gcm.On Mon, Jan 19, 2015, 5:26 AM Brent Cook notifications@github.com wrote:
Hi @calvinmetcalf https://github.com/calvinmetcalf - are you having
trouble getting those ciphers to work with LibreSSL? I believe they are the
default when using TLS 1.2, unless I have misunderstood the problem. I just
checked with 'openssl s_client':New, TLSv1/SSLv3, Cipher is ECDHE-RSA-CHACHA20-POLY1305
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
Protocol : TLSv1.2
Cipher : ECDHE-RSA-CHACHA20-POLY1305—
Reply to this email directly or view it on GitHub
#428 (comment).
Got it, thanks for the clarification.
Looks like this isn't going to viable for the foreseeable future? Re-open if it is.
@calvinmetcalf, you don't happen to have an integration branch you were working from, do you? I wouldn't mind taking a look before the next LibreSSL release.
I just installed libressl and compiled io.js with the flags to use the
system openssl
On Sat, Jan 31, 2015, 11:24 AM Brent Cook notifications@github.com wrote:
@calvinmetcalf https://github.com/calvinmetcalf, you don't happen to
have an integration branch you were working from, do you? I wouldn't mind
taking a look before the next LibreSSL release.—
Reply to this email directly or view it on GitHub
#428 (comment).
FWIW, only 5 of the 13 OpenSSL vulnerabilities announced today affected LibreSSL as well. The two high-severity ones were not among them. Details: http://undeadly.org/cgi?action=article&sid=20150319145126
Things in the pipeline for 2.2.x include AIX, Cygwin, Visual Studio support, and wider support for optimizations (currently only ELF/OS X x64 is supported). In general, expect libtls to expand in features and improve usability, more code to be pruned and simplified.
https://news.ycombinator.com/item?id=9217211
LibreSSL 2.2.x is expected to be released later this year around August.
2.0.0 and later don't work with libressl. Earlier versions worked fine.
I am aware.
fyi: I started a node branch that allows to build node with libressl: https://github.com/Gottox/node
@Gottox could you rebase that so the changes are easier to review? I still think that a native wrapper around openssl/libressl is the way forward but it's always interesting to have a look.
To be honest, it's not intended to submit that upstream. It's just a back port of the old API that was replaced in iojs-2.0 to make node-4 compile on VoidLinux using LibreSSL.
But if people are interested, I'll add proper commit messages and rebase.
Looks like yesterday's fork drama (caused by ignorance of reality) taught people nothing. We don't support this, we don't support that, oh my - another fork.
It's not a fork, it's a patchset used in VoidLinux.
@Gottox, there IS an interest in LibreSSL/BoringSSL. And you guys know it. Users do read comments. Including stuff between lines. And users getting scared all the time they see this "we are not interested in smaller projects pushing technically higher standards, we better stick with old good fat guy".
Right now, OpenBSD ports team is forced to use bundled OpenSSL for nodejs port instead of LibreSSL (which project develops). What an irony.
But you guys still thinking, is there any interest, or not.
Looking at the comments here I see that LibreSSL was discarded mostly for not building on MSVC.
So here's an update:
As of LibreSSL 2.2.2, Visual Studio Native builds can be produced using CMake.
This produces ABI-compatible libraries for linking with native code generated
by Visual Studio.
https://github.com/libressl-portable/portable/blob/master/README.windows#L43-L45
LibreSSL 2.2.2 was relased on Aug 5, 2015. There have been 9 releases since then.
Currently the latest stable release is 2.3.6 and unstable is 2.4.1
Considering that most of the posts on https://nodejs.org/en/blog/vulnerability/ are related to OpenSSL and that the biggest obstacle to switch to LibreSSL was the lack of MSVC support which is no longer the case, maybe it's time to reconsider LibreSSL adoption in Node?
I'll reopen, we can investigate. It won't be an overnight change though.
That are great news!
Considering that most of the posts on https://nodejs.org/en/blog/vulnerability/ are related to OpenSSL ...
Let's not be too romantic about LibreSSL, cruising through recent release notes it looks like we'd probably be doing releases just as frequently if we switched than if we stuck with OpenSSL, albeit with slightly less severity overall. The new OpenSSL team (thanks to very heavy investment from the Core Infrastructure Initiative) is rapidly improving the codebase and have high hopes for a future where they can nullify the main arguments in favour of Libre and Boring and reunite the major forks again under one banner.
... and reunite the major forks again under one banner.
A related note on the libressl mailing list recently about importing a new feature from the OpenSSL 1.1 API:
...
BoringSSL hasn't pulled in X509_NAME_get0_der either yet - so I think we will
be taking what I would describe as a cautious and selective approach to
new features from OpenSSL - During the same time as we've moved from about
750,000 of code at the fork to about 350,000 - OpenSSL is now over 1,000,000
lines - So we're probably not going to be about wholesale code importing
from OpenSSL - We will be taking things selectively and with a degree
of caution.
...
@rvagg If the "slightly less severity overall" as you put it means that I get only 5 out of every 13 OpenSSL vulnerabilities as witten by @pesho above, then it is at least some progress. There were 9 entries on Node vulnerability blog during this and the last year, 6 of which were related to OpenSSL. I'm sure OpenSSL have good intentions but currently they are probably a world record holder for the number of CVE entries and they are the number one cause of Node vulnerabilities which is not something to be taken lightly.
@timkuijsten Mac OS X has already switched to LibreSSL in 10.11 so I guess those new features would either have to be incorporated into LibreSSL by Apple or other downstream vendors for interoperability if they are so crucial, or not relied upon anyway.
@Gottox Thanks for the work you've done. I hope it goes into Node and we'll have an option to use either OpenSSL or LibreSSL to make everyone happy.
Mac OS X has already switched to LibreSSL in 10.11 so I guess those new features would either have to be incorporated into LibreSSL by Apple or other downstream vendors for interoperability if they are so crucial, or not relied upon anyway.
@rsp isn't it only included with the openssh that ships with OS X?
On OS X 10.11.5:
$ openssl version
OpenSSL 0.9.8zh 14 Jan 2016
$ ssh -V
OpenSSH_6.9p1, LibreSSL 2.1.8
@timkuijsten You're right. I've read about it in the article by @FredericJacobs. Good catch. Thanks.
@rsp The problem with my fork is that even in minor releases of node there are changes towards using new openssl APIs.
I gave up somewhere around node-4.3 and am now building node for VoidLinux with builtin openssl. Currently node.js is the only package in our distribution that relies on openssl and cannot be build with libressl.
There are some people investigating in adding openssl-1.x APIs to libressl, but it doesn't look like it's coming anytime soon. Their focus is on promoting libressl's libtls library.
@Gottox Are those changes to use the new OpenSSL APIs critical for the security/functionality of Node? Do you think that those could be abstracted away or maybe avoided altogether to maintain the compatibility with LibreSSL?
I see two solutions: 1) All calls to OpenSSL could use a common subset of OpenSSL and LibreSSL APIs to make the porting most straightforward, or 2) those calls could be abstracted away using some small Node SSL API. No. 1 would need changing the OpenSSL API used today, no. 2 would not but would add a lever of indirection instead. That abstraction could use the same new OpenSSL API calls as are used today and then anyone interested could add support for LibreSSL or other library like BoringSSL, wolfSSL or anything else, in one place with no risk that any minor change would break it.
A third solution would be maintaining a LibreSSL fork of Node or a custom patch set which would not be an optimal solution but this is unfortunately what is going on with Void Linux, Gentoo etc.
Gentoo is maintaining their own patches for Node and npm to work with LibreSSL.
FreeBSD - in The state of LibreSSL in FreeBSD by @attilagyorffy, Node is the only software causing problems.
HardenedBSD - AFAIK @Sp1l is working on adding LibreSSL as alternative provider of libcrypto and libssl. Sooner or later Node will become a problem there if it's the only software that can't work with LibreSSL.
OpenBSD - they had problems with building Node and they added exceptions for Node so that SSL provider cannot be chosen like for other packages, with a TODO to re-add the choice when it works for Node. See commit somasis/arbor@b6bdfcb
During the big Node update from 0.10.35 to 4.2.1 in OpenBSD ports last year @qbit wrote "Build against node's OpenSSL (this one hurts, but is unavoidable currently)." I'm not sure if it is the only package in OpenBSD ports that uses a bundled OpenSSL library?
I'm wondering what is the best solution to this problem. The fragmentation of the Node patchsets doesn't seem to be optimal because the versions diverge and the work that was done by @Gottox and others is lost on the newer versions. On the other hand having Node as the only package that uses OpenSSL on systems like Void Linux or OpenBSD would make it look unfairly insecure in comparison to other packages that don't have to use OpenSSL, because Node would be the only package on those systems affected by all OpenSSL vulnerabilities, and would need to get security updates every time because it uses a bundled OpenSSL library so updating the system's OpenSSL would not be enough.
@rsp as I already said, gentoo's nodejs patchset is based on my abandoned nodejs fork (last release being based on 4.3.2). The patchset provided by gentoo is completely broken
We at VoidLinux ship over 7000 packages, all build against libressl. Nodejs is the only exception where we're forced to use the bundled openssl.
I don't think an SSL abstraction layer will do any good except that it will introduce new bugs and making a hard life for developers. Personally I would be satisfied if node wouldn't break a patchset with nearly every minor release.
I am working on switching alpine over to libressl and got bitten by this. I am not happy with building node with the bundled openssl. What happens if 3rd party modules are built with system libressl and node is built with bundled openssl?
@ncopa I don't think theres a statement about supporting 3rd party modules building against libressl either.
Someone stepping up and working on an abstraction layer would probably be the fastest way forward.
@jbergstroem i suspect that if you mix system libraries which uses libressl - or even openssl-1.1.x, while the nodejs itself is build with bundled openssl-1.0.x, then you will end up with major breakage.
This is the third time I state this: An abstraction API doesn't make any sense in this case:
libressl, boringssl, openssl-0.x, and openssl-1.x (including 1.1.x) are basicly 99% the same API. If you choose to support any of them except openssl-1.x compiling it with any other is a no-brainer.
I'm doing a bit of bug tracker cleanup. There are no plans to switch to libressl so I'm going to go ahead and close this.
I have created a IRC channel ( #node-ssl ) on freenode for discussing a path forward on this issue. Anyone interested in adding *SSL support for Node, please hop on! I figure if we all coordinate we can come up with a mutually acceptable solution.
+1
Here's something for y'all to play with if you have the interest and time in rounding it out: #9376 — most of the way to supporting LibreSSL but still a few pieces not quite working. No guarantee that this'll ever get merged mind you.
Node would be the only package on those systems affected by all OpenSSL vulnerabilities, and would need to get security updates every time because it uses a bundled OpenSSL library so updating the system's OpenSSL would not be enough.
@rsp node can be built against the system OpenSSL, it doesn't have to build against the builtin
even with core initiative financial support, openssl is still a mess, bug reports get ignored since years, for example openssl still does not build against musl libc even though i reported the bugs with attached patches in 2011(!), and they have an idiotic perl-based build system, that's ultra-slow and unwanted because we dont want to have to pull perl dependencies into our distro to build such a core piece of infrastructure.
since libressl uses a non-retarded standard autoconf build system, it builds in less than half of the time that openssl needs.
additionally libressl is much more secure, there have been numerous openssl bugs now libressl was not vulnerable to.
the only APIs that libressl removed are those that are insecure and should not be used.
so you guys would be better off not using them as well, and then nodejs build would work automatically against libressl, openssl, and everyone else.
you really should'nt be the only major hurdle in the way of users that want to replace the ever-broken openssl with something better.
Would be great to see something advancing here. It's been 2 years since last comment.
Another year and still no news?
Hack up or put up!
@qbit I believe @Gottox had a working implementation some time ago so the question by @JoeUser78 is not unreasonable.
Posting now that libressl has removed the functions neccessary for this ugly hack to work as of 3.9.0 . Strange how github won't let me upload this... https://pastebin.com/AhK7ynSu
Of note; SetRsaOaepLabel is probably leaking memory using libre or openssl. This patch is a pile of miserable hacks from various sources. The functionality of nodejs-20.11.1 was tested against building recent versions of firefox and invoking via commandline, which was found working.