plans on incorporating LibreSSL

[timkuijsten]

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]

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]

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

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

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]

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

[piscisaureus]

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]

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

[bnoordhuis]

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]

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

[bnoordhuis]

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

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]

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]

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

[busterb]

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]

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]

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]

Got it, thanks for the clarification.

[Fishrock123]

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

[busterb]

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

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]

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]

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]

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

[Fishrock123]

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

[lucy]

I am aware.

[Gottox]

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

[servantoftestator]

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.