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