New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

plans on incorporating LibreSSL #428

Closed
timkuijsten opened this Issue Jan 14, 2015 · 57 comments

Comments

Projects
None yet
@timkuijsten
Contributor

timkuijsten commented Jan 14, 2015

Is there any experience with or are there any plans on replacing OpenSSL with the leaner and meaner LibreSSL with it's new libtls API now that both io.js and LibreSSL have there first releases out?

@timkuijsten

This comment has been minimized.

Contributor

timkuijsten commented Jan 14, 2015

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.
@domenic

This comment has been minimized.

Member

domenic commented Jan 14, 2015

+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.

@timkuijsten

This comment has been minimized.

Contributor

timkuijsten commented Jan 14, 2015

@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

@mscdex

This comment has been minimized.

Contributor

mscdex commented Jan 14, 2015

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.

@timkuijsten

This comment has been minimized.

Contributor

timkuijsten commented Jan 14, 2015

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/portable#59

@piscisaureus

This comment has been minimized.

Member

piscisaureus commented Jan 14, 2015

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.

@timkuijsten

This comment has been minimized.

Contributor

timkuijsten commented Jan 14, 2015

@piscisaureus I can imagine, unfortunately it doesn't look like that's what they're planning: libressl-portable/portable#59 (comment)

@bnoordhuis

This comment has been minimized.

Member

bnoordhuis commented Jan 15, 2015

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.

@timkuijsten

This comment has been minimized.

Contributor

timkuijsten commented Jan 15, 2015

@bnoordhuis can you explain a bit what you mean with "the way TLS is implemented in io.js is not the common case"?

@bnoordhuis

This comment has been minimized.

Member

bnoordhuis commented Jan 15, 2015

@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.

@bcook-r7

This comment has been minimized.

bcook-r7 commented Jan 15, 2015

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.

@calvinmetcalf

This comment has been minimized.

Member

calvinmetcalf commented Jan 15, 2015

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

@calvinmetcalf

This comment has been minimized.

Member

calvinmetcalf commented Jan 17, 2015

in other news doesn't look like libressl has implemented the chacha20/poly1305 aead yet

@busterb

This comment has been minimized.

busterb commented Jan 19, 2015

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
@calvinmetcalf

This comment has been minimized.

Member

calvinmetcalf commented Jan 19, 2015

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).

@calvinmetcalf

This comment has been minimized.

Member

calvinmetcalf commented Jan 19, 2015

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).

@busterb

This comment has been minimized.

busterb commented Jan 24, 2015

Got it, thanks for the clarification.

@Fishrock123

This comment has been minimized.

Member

Fishrock123 commented Jan 30, 2015

Looks like this isn't going to viable for the foreseeable future? Re-open if it is.

@busterb

This comment has been minimized.

busterb commented Jan 31, 2015

@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.

@calvinmetcalf

This comment has been minimized.

Member

calvinmetcalf commented Jan 31, 2015

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).

@pesho

This comment has been minimized.

Member

pesho commented Mar 19, 2015

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

@timkuijsten

This comment has been minimized.

Contributor

timkuijsten commented Mar 20, 2015

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.

@lucy

This comment has been minimized.

lucy commented May 13, 2015

2.0.0 and later don't work with libressl. Earlier versions worked fine.

@Fishrock123

This comment has been minimized.

Member

Fishrock123 commented May 13, 2015

@lucy Please see #1622 - we don't actually support LibreSSL, although a version compatible with OpenSSL 1.0.2a might work.

@lucy

This comment has been minimized.

lucy commented May 13, 2015

I am aware.

@Gottox

This comment has been minimized.

Gottox commented Sep 21, 2015

fyi: I started a node branch that allows to build node with libressl: https://github.com/Gottox/node

@rvagg

This comment has been minimized.

Member

rvagg commented Jun 27, 2016

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.

@timkuijsten

This comment has been minimized.

Contributor

timkuijsten commented Jun 27, 2016

... 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.
...

http://marc.info/?l=libressl&m=146652754125628&w=2

@rsp

This comment has been minimized.

Contributor

rsp commented Jun 29, 2016

@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.

@timkuijsten

This comment has been minimized.

Contributor

timkuijsten commented Jun 29, 2016

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
@rsp

This comment has been minimized.

Contributor

rsp commented Jun 29, 2016

@timkuijsten You're right. I've read about it in the article by @FredericJacobs. Good catch. Thanks.

@Gottox

This comment has been minimized.

Gottox commented Jun 30, 2016

@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.

@rsp

This comment has been minimized.

Contributor

rsp commented Jul 8, 2016

@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.

@Gottox

This comment has been minimized.

Gottox commented Jul 8, 2016

@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.

@Fishrock123 Fishrock123 added feature request and removed discuss labels Jul 19, 2016

@ncopa

This comment has been minimized.

Contributor

ncopa commented Oct 5, 2016

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?

@jbergstroem

This comment has been minimized.

Member

jbergstroem commented Oct 5, 2016

@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.

@ncopa

This comment has been minimized.

Contributor

ncopa commented Oct 5, 2016

@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.

@Gottox

This comment has been minimized.

Gottox commented Oct 6, 2016

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.

@Gottox

This comment has been minimized.

Gottox commented Oct 19, 2016

@ncopa: related: #589

@bnoordhuis

This comment has been minimized.

Member

bnoordhuis commented Oct 21, 2016

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.

@bnoordhuis bnoordhuis closed this Oct 21, 2016

@qbit

This comment has been minimized.

Contributor

qbit commented Oct 21, 2016

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.

@archenroot

This comment has been minimized.

archenroot commented Oct 23, 2016

+1

@rvagg

This comment has been minimized.

Member

rvagg commented Oct 31, 2016

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.

@sam-github

This comment has been minimized.

Member

sam-github commented Oct 31, 2016

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

@rofl0r

This comment has been minimized.

rofl0r commented Jan 15, 2017

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.

@llacroix

This comment has been minimized.

llacroix commented Feb 17, 2017

Would be great to see something advancing here. It's been 2 years since last comment.

@JoeUser78

This comment has been minimized.

JoeUser78 commented Feb 8, 2018

Another year and still no news?

@qbit

This comment has been minimized.

Contributor

qbit commented Feb 8, 2018

Hack up or put up!

@rsp

This comment has been minimized.

Contributor

rsp commented Feb 8, 2018

@qbit I believe @Gottox had a working implementation some time ago so the question by @JoeUser78 is not unreasonable.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment