Open Neustradamus opened 10 years ago
Nice idea. I'm afraid we can't assign it high priority right now, but pull requests are always welcome. How much is LibreSSL API different compared to OpenSSL? You can check https://github.com/esl/MongooseIM/blob/master/apps/ejabberd/c_src/tls_drv.c to see what OpenSSL functions and header files are used.
Until OpenBSD team will provide a portable LibreSSL for Linux, we'd better avoid LibreSSL. There's another alternative -- BoringSSL which is a commercial-grade fork of OpenSSL (that is maintained by Google)
https://boringssl.googlesource.com/boringssl/
How much is LibreSSL API different compared to OpenSSL?
LibreSSL is API compatible with OpenSSL 1.0.1 which means it "just works" with HEAD (as of ~ Jan 28) granted this change is introduced to rebar.config
- [{".*", "priv/lib/tls_drv.so", ["c_src/tls_drv.c"], [{env, [{"LDFLAGS", "$LDFLAGS -lssl"}]}]},
+ [{".*", "priv/lib/tls_drv.so", ["c_src/tls_drv.c"], [{env, [{"CFLAGS", "$CFLAGS"}, {"LDFLAGS", "$LDFLAGS -lssl"}]}]},
then once you get LibreSSL built (tested on Ubuntu LTS 14.04.x)
$ CFLAGS=-I/usr/local/libressl/include/ make
should build MongooseIM against it:
$ LD_LIBRARY_PATH=/usr/local/libressl/lib ldd apps/ejabberd/priv/lib/tls_drv.so
linux-vdso.so.1 => (0x00007ffd919f9000)
libssl.so.35 => /usr/local/libressl/lib/libssl.so.35 (0x00007fdcab4c0000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fdcab0fb000)
libcrypto.so.35 => /usr/local/libressl/lib/libcrypto.so.35 (0x00007fdcaacf1000)
/lib64/ld-linux-x86-64.so.2 (0x00007fdcab92c000)
P.S. Must read http://insanecoding.blogspot.se/2014/04/libressl-good-and-bad.html
Disclaimer: I'm not crypto type!
Thanks for investigating this. How about the ssl
lib provided by Erlang/OTP. Cowboy uses it and we use cowboy for BOSH and WS handling. I guess it's only a matter of compiling Erlang/OTP with libressl
, am I right?
I guess it's only a matter of compiling Erlang/OTP with libressl, am I right?
Yes, I think so too. We should try get @legoscia in the loop. He works on SSL (in Erlang/OTP) AFAIR
@ysz Good stuff! WRT BoringSSL, this is from its PORTING.md:
Note: BoringSSL does not have a stable API or ABI. It must be updated with its consumers. It is not suitable for, say, a system library in a traditional Linux distribution. For instance, Chromium statically links the specific revision of BoringSSL it was built against. Likewise, Android’s system-internal copy of BoringSSL is not exposed by the NDK and must not be used by third-party applications.
Which is not very different from the way regular Erlang libraries are distributed, but still a thing to keep in mind.
BoringSSL does not have a stable API or ABI. It must be updated with its consumers
@erszcz that's the price to pay for up-to-date security patches from Google upstream ;)
I guess it's only a matter of compiling Erlang/OTP with libressl, am I right?
In principle, yes. I'm not sure if anyone has tried it. In theory it should just work, but if it does, it would be a good idea to post about it on erlang-questions so other people know for sure :)
Note that the Erlang/OTP ssl application only uses OpenSSL for crypto primitives; it has its own implementation of the TLS protocol, so OpenSSL vulnerabilities are not necessarily present there. (This is unlike tls_drv
, which uses the OpenSSL TLS implementation.)
it has its own implementation of the TLS protocol
o O
@legoscia nice to know! Thanks!
Oh, in fact, the OTP team has already committed some fixes to run the test suite with LibreSSL.
Add LibreSSL support: