[Libwebsockets] libwebsockets 3.2.2 + wolfssl 4.3.0 issue
andy at warmcat.com
Fri Mar 20 10:39:54 CET 2020
On Fri, Mar 20, 2020 at 08:41, Alessandro Longobardi
<alessandro.longobardi at vrmedia.it> wrote:
> I’m trying to use libwebsockets with wolfssl (instead of openssl)
> on raspberry pi 0 (as i read wolfssl is more efficient on embedded
> platform than openssl).
I never looked closely at wolfssl, but certainly mbedtls is very slow
compared to openssl's accelerations for the architectures it supports.
> I have a videostreaming application that works without problem using
> libwebsockets 3.2.2 with openssl.
> I downloaded from the official github repository the release 4.3.0
> (<https://github.com/wolfSSL/wolfssl/tree/v4.3.0-stable>), then i use
> the following commands in order to compile it:
> ./autogen.sh./configure –enable-opensslextra --enable-libwebsockets
> (this is a new options in 4.3.0)makesudo make install
> Then on libwebsockets release 3.2.2 i use:
> cmake .. -DLWS_WITH_WOLFSSL=1
Right it's all pretty reasonable.
> During compilation process it finds some errors:
> In lib/tls/openssl/ssl.c it cannot find the declaration of
> “SSL_get_cipher_bits” and “SSL_get_cipher_version”.
No it's already gone off the rails... the problem is coming at cmake,
it does a lot of tests to understand what's in your tls lib. There are
a lot of versions of openssl that have conflicting apis depending on
exact version, lws just empirically finds out at cmake time what you
have rather than trying to know every version or fork of it. What
cmake discovers during these tests has to match the reality of your
library or it will try to build with things that don't exist in your
The tests are all failing with wolfssl due to problems finding the
includes in the tests... it will very happily match anything that had
an explicit or implicit -I for "openssl/xxx.h", so typically it's
actually using your distro openssl -dev[el] package headers. I fixed
this (and the rest of the things described here) with a patch on master
Then, the tests use CHECK_FUNCTION_EXISTS, but wolfssl approach is to
actually have wolfSSL_ functions and #define the openssl function names
to their wolfSSL_ function names. So I adapted the tests to use
wolfSSL_ function name prepend when wolfssl enabled. Finally the cmake
tests look like they are actually checking the apis.
That uncovers a true problem, the install wolfssl headers contain this
/* warning for not using harden build options (default with
#if (defined(USE_FAST_MATH) && !defined(TFM_TIMING_RESISTANT)) || \
(defined(HAVE_ECC) && !defined(ECC_TIMING_RESISTANT)) || \
(!defined(NO_RSA) && !defined(WC_RSA_BLINDING) &&
!defined(HAVE_FIPS) && \
#warning "For timing resistance / side-channel attack
prevention consider using harden options"
#pragma message("Warning: For timing resistance /
side-channel attack prevention consider using harden options")
#warning "For timing resistance / side-channel attack prevention
consider using harden options" [-Werror=cpp]
1995 | #warning "For timing resistance / side-channel
attack prevention consider using harden options"
and of course we promote all warnings to errors.
Somehow adding --enable-harden to the wolfssl config doesn't make it go
away... I commented it in the installed header. You probably actually
do want to harden it but that seems wholly a wolfssl issue.
Lastly the openssl compatibility apis don't quite match for const
pointers or not, I fixed these up as well. With that here at least on
Fedora 31 it was happy.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Libwebsockets