Repository navigation
plans on incorporating LibreSSL #428
Description
Activity
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-codeIs 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#59Are 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-POLY1305Yes 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).35 remaining items
@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.
Reacted by Alessandro Barbieri and BrianI 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.
Reacted by Ladislav Zitka+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.
Reacted by Tim Kuijsten, qbit, Arnaud Lefebvre, gmm42 and AJ JordanReacted by Enno T. Boland and AJ JordanNode 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.Reacted by Rafał Pocztarski, gmm42, William, Groggy, Thiago, Matt Simerson, Raphael Cohn, livagit, Danlock, Rasmus Thomsen and 3 moreWould be great to see something advancing here. It's been 2 years since last comment.
Reacted by Rafał Pocztarski, livagit, Gaspard d'Hautefeuille and Alessandro BarbieriReacted by Johan BergströmAnother year and still no news?
Reacted by Rafał Pocztarski and Alessandro BarbieriHack 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.
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?