[Libwebsockets] libwebsockets 3.2.2 + wolfssl 4.3.0 issue

[Andy Green]

On Fri, Mar 20, 2020 at 08:41, Alessandro Longobardi 
<alessandro.longobardi at vrmedia.it> wrote:
> Hi,
> 
> 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 
> -DLWS_WOLFSSL_INCLUDE_DIRS=/usr/local/include/wolfssl 
> -DLWS_WOLFSSL_LIBRARIES=/usr/local/lib/libwolfssl.so 
> -DCMAKE_BUILD_TYPE=DEBUGmake
> 

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 
library version.

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 
/ v4.0-stable.

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 
./configure) */
#ifndef WC_NO_HARDEN
    #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) && \
            !defined(WC_NO_RNG))

        #ifndef _MSC_VER
            #warning "For timing resistance / side-channel attack 
prevention consider using harden options"
        #else
            #pragma message("Warning: For timing resistance / 
side-channel attack prevention consider using harden options")
        #endif
    #endif
#endif

/usr/local/include/wolfssl/wolfcrypt/settings.h:1995:14: error: 
#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.

-Andy


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://libwebsockets.org/pipermail/libwebsockets/attachments/20200320/392e9880/attachment-0001.htm>