[Openvpn-devel] Support for wolfSSL in OpenVPN

Message ID 20200616180046.8069-1-juliusz@wolfssl.com
State Changes Requested
Headers show
Series [Openvpn-devel] Support for wolfSSL in OpenVPN | expand

Commit Message

Juliusz Sosinowicz June 16, 2020, 8 a.m. UTC
This patch adds support for wolfSSL in OpenVPN. Support is added by using wolfSSL's OpenSSL compatibility layer. Function calls are left unchanged and instead the OpenSSL includes point to wolfSSL headers and OpenVPN is linked against the wolfSSL library.

As requested by OpenVPN maintainers, this patch does not include wolfssl/options.h on its own. By defining the macro EXTERNAL_OPTS_OPENVPN in the configure script wolfSSL will include wolfssl/options.h on its own (change added in https://github.com/wolfSSL/wolfssl/pull/2825). The patch adds an option `--disable-wolfssl-options-h` in case the user would like to supply their own settings file for wolfSSL.

wolfSSL:
Support added in: https://github.com/wolfSSL/wolfssl/pull/2503
```
git clone https://github.com/wolfSSL/wolfssl.git
cd wolfssl
./autogen.sh
./configure --enable-openvpn
make
sudo make install
```

OpenVPN:
```
autoreconf -i -v -f
./configure --with-crypto-library=wolfssl
make
make check
sudo make install
```

Signed-off-by: Juliusz Sosinowicz <juliusz@wolfssl.com>
---
 configure.ac          | 94 ++++++++++++++++++++++++++++++++++++++++++-
 src/openvpn/syshead.h |  3 +-
 2 files changed, 94 insertions(+), 3 deletions(-)

Comments

Juliusz Sosinowicz July 14, 2020, 10:26 p.m. UTC | #1
Hi Everyone,

do you have an update on the latest patch I sent? There have been 
updates to wolfSSL to fix the remaining issues brought up last time.

Thanks
Juliusz

On 16/06/2020 20:00, Juliusz Sosinowicz wrote:
> This patch adds support for wolfSSL in OpenVPN. Support is added by using wolfSSL's OpenSSL compatibility layer. Function calls are left unchanged and instead the OpenSSL includes point to wolfSSL headers and OpenVPN is linked against the wolfSSL library.
>
> As requested by OpenVPN maintainers, this patch does not include wolfssl/options.h on its own. By defining the macro EXTERNAL_OPTS_OPENVPN in the configure script wolfSSL will include wolfssl/options.h on its own (change added in https://github.com/wolfSSL/wolfssl/pull/2825). The patch adds an option `--disable-wolfssl-options-h` in case the user would like to supply their own settings file for wolfSSL.
>
> wolfSSL:
> Support added in: https://github.com/wolfSSL/wolfssl/pull/2503
> ```
> git clone https://github.com/wolfSSL/wolfssl.git
> cd wolfssl
> ./autogen.sh
> ./configure --enable-openvpn
> make
> sudo make install
> ```
>
> OpenVPN:
> ```
> autoreconf -i -v -f
> ./configure --with-crypto-library=wolfssl
> make
> make check
> sudo make install
> ```
>
> Signed-off-by: Juliusz Sosinowicz <juliusz@wolfssl.com>
> ---
>   configure.ac          | 94 ++++++++++++++++++++++++++++++++++++++++++-
>   src/openvpn/syshead.h |  3 +-
>   2 files changed, 94 insertions(+), 3 deletions(-)
>
> diff --git a/configure.ac b/configure.ac
> index 273a8d1b..56d63555 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -269,16 +269,23 @@ AC_ARG_WITH(
>   
>   AC_ARG_WITH(
>   	[crypto-library],
> -	[AS_HELP_STRING([--with-crypto-library=library], [build with the given crypto library, TYPE=openssl|mbedtls @<:@default=openssl@:>@])],
> +	[AS_HELP_STRING([--with-crypto-library=library], [build with the given crypto library, TYPE=openssl|mbedtls|wolfssl @<:@default=openssl@:>@])],
>   	[
>   		case "${withval}" in
> -			openssl|mbedtls) ;;
> +			openssl|mbedtls|wolfssl) ;;
>   			*) AC_MSG_ERROR([bad value ${withval} for --with-crypto-library]) ;;
>   		esac
>   	],
>   	[with_crypto_library="openssl"]
>   )
>   
> +AC_ARG_ENABLE(
> +	[wolfssl-options-h],
> +	[AS_HELP_STRING([--disable-wolfssl-options-h], [Disable including options.h in wolfSSL @<:@default=yes@:>@])],
> +	,
> +	[enable_wolfssl_options_h="yes"]
> +)
> +
>   AC_ARG_VAR([PLUGINDIR], [Path of plug-in directory @<:@default=LIBDIR/openvpn/plugins@:>@])
>   if test -n "${PLUGINDIR}"; then
>   	plugindir="${PLUGINDIR}"
> @@ -1022,6 +1029,89 @@ elif test "${with_crypto_library}" = "mbedtls"; then
>   	AC_DEFINE([ENABLE_CRYPTO_MBEDTLS], [1], [Use mbed TLS library])
>   	CRYPTO_CFLAGS="${MBEDTLS_CFLAGS}"
>   	CRYPTO_LIBS="${MBEDTLS_LIBS}"
> +
> +elif test "${with_crypto_library}" = "wolfssl"; then
> +	AC_ARG_VAR([WOLFSSL_CFLAGS], [C compiler flags for wolfssl])
> +	AC_ARG_VAR([WOLFSSL_LIBS], [linker flags for wolfssl])
> +	AC_ARG_VAR([WOLFSSL_DIR], [Path to the wolfssl directory @<:@default=/usr/local/include/wolfssl@:>@])
> +	if test -n "${WOLFSSL_DIR}"; then
> +		wolfssldir="${WOLFSSL_DIR}"
> +	else
> +		wolfssldir="/usr/local/include/wolfssl"
> +	fi
> +
> +	saved_CFLAGS="${CFLAGS}"
> +	saved_LIBS="${LIBS}"
> +
> +	if test -z "${WOLFSSL_CFLAGS}" -a -z "${WOLFSSL_LIBS}"; then
> +		# if the user did not explicitly specify flags, try to autodetect
> +		LIBS="${LIBS} -lwolfssl -lm -pthread"
> +		AC_CHECK_LIB(
> +			[wolfssl],
> +			[wolfSSL_Init],
> +			[],
> +			[AC_MSG_ERROR([Could not link wolfSSL library.])]
> +		)
> +		AC_CHECK_HEADER([wolfssl/options.h],,[AC_MSG_ERROR([wolfSSL header wolfssl/options.h not found!])])
> +	fi
> +
> +	AC_DEFINE([HAVE_HMAC_CTX_NEW], [1], [Emulate AC_CHECK_FUNCS since these are defined as macros])
> +	AC_DEFINE([HAVE_HMAC_CTX_FREE], [1], [Emulate AC_CHECK_FUNCS since these are defined as macros])
> +	AC_DEFINE([HAVE_HMAC_CTX_RESET], [1], [Emulate AC_CHECK_FUNCS since these are defined as macros])
> +	AC_DEFINE([HAVE_EVP_MD_CTX_NEW], [1], [Emulate AC_CHECK_FUNCS since these are defined as macros])
> +	AC_DEFINE([HAVE_EVP_MD_CTX_FREE], [1], [Emulate AC_CHECK_FUNCS since these are defined as macros])
> +	AC_DEFINE([HAVE_EVP_MD_CTX_RESET], [1], [Emulate AC_CHECK_FUNCS since these are defined as macros])
> +	AC_DEFINE([HAVE_EVP_CIPHER_CTX_RESET], [1], [Emulate AC_CHECK_FUNCS since these are defined as macros])
> +	AC_DEFINE([HAVE_OPENSSL_VERSION], [1], [Emulate AC_CHECK_FUNCS since these are defined as macros])
> +	AC_DEFINE([HAVE_SSL_CTX_GET_DEFAULT_PASSWD_CB], [1], [Emulate AC_CHECK_FUNCS since these are defined as macros])
> +	AC_DEFINE([HAVE_SSL_CTX_GET_DEFAULT_PASSWD_CB_USERDATA], [1], [Emulate AC_CHECK_FUNCS since these are defined as macros])
> +	AC_DEFINE([HAVE_SSL_CTX_SET_SECURITY_LEVEL], [1], [Emulate AC_CHECK_FUNCS since these are defined as macros])
> +	AC_DEFINE([HAVE_X509_GET0_NOTBEFORE], [1], [Emulate AC_CHECK_FUNCS since these are defined as macros])
> +	AC_DEFINE([HAVE_X509_GET0_NOTAFTER], [1], [Emulate AC_CHECK_FUNCS since these are defined as macros])
> +	AC_DEFINE([HAVE_X509_GET0_PUBKEY], [1], [Emulate AC_CHECK_FUNCS since these are defined as macros])
> +	AC_DEFINE([HAVE_X509_STORE_GET0_OBJECTS], [1], [Emulate AC_CHECK_FUNCS since these are defined as macros])
> +	AC_DEFINE([HAVE_X509_OBJECT_FREE], [1], [Emulate AC_CHECK_FUNCS since these are defined as macros])
> +	AC_DEFINE([HAVE_X509_OBJECT_GET_TYPE], [1], [Emulate AC_CHECK_FUNCS since these are defined as macros])
> +	AC_DEFINE([HAVE_EVP_PKEY_ID], [1], [Emulate AC_CHECK_FUNCS since these are defined as macros])
> +	AC_DEFINE([HAVE_EVP_PKEY_GET0_RSA], [1], [Emulate AC_CHECK_FUNCS since these are defined as macros])
> +	AC_DEFINE([HAVE_EVP_PKEY_GET0_DSA], [1], [Emulate AC_CHECK_FUNCS since these are defined as macros])
> +	AC_DEFINE([HAVE_EVP_PKEY_GET0_EC_KEY], [1], [Emulate AC_CHECK_FUNCS since these are defined as macros])
> +	AC_DEFINE([HAVE_RSA_SET_FLAGS], [1], [Emulate AC_CHECK_FUNCS since these are defined as macros])
> +	AC_DEFINE([HAVE_RSA_BITS], [1], [Emulate AC_CHECK_FUNCS since these are defined as macros])
> +	AC_DEFINE([HAVE_RSA_GET0_KEY], [1], [Emulate AC_CHECK_FUNCS since these are defined as macros])
> +	AC_DEFINE([HAVE_RSA_SET0_KEY], [1], [Emulate AC_CHECK_FUNCS since these are defined as macros])
> +	AC_DEFINE([HAVE_DSA_GET0_PQG], [1], [Emulate AC_CHECK_FUNCS since these are defined as macros])
> +	AC_DEFINE([HAVE_DSA_BITS], [1], [Emulate AC_CHECK_FUNCS since these are defined as macros])
> +	AC_DEFINE([HAVE_RSA_METH_NEW], [1], [Emulate AC_CHECK_FUNCS since these are defined as macros])
> +	AC_DEFINE([HAVE_RSA_METH_FREE], [1], [Emulate AC_CHECK_FUNCS since these are defined as macros])
> +	AC_DEFINE([HAVE_RSA_METH_SET_PUB_ENC], [1], [Emulate AC_CHECK_FUNCS since these are defined as macros])
> +	AC_DEFINE([HAVE_RSA_METH_SET_PUB_DEC], [1], [Emulate AC_CHECK_FUNCS since these are defined as macros])
> +	AC_DEFINE([HAVE_RSA_METH_SET_PRIV_ENC], [1], [Emulate AC_CHECK_FUNCS since these are defined as macros])
> +	AC_DEFINE([HAVE_RSA_METH_SET_PRIV_DEC], [1], [Emulate AC_CHECK_FUNCS since these are defined as macros])
> +	AC_DEFINE([HAVE_RSA_METH_SET_INIT], [1], [Emulate AC_CHECK_FUNCS since these are defined as macros])
> +	AC_DEFINE([HAVE_RSA_METH_SET_SIGN], [1], [Emulate AC_CHECK_FUNCS since these are defined as macros])
> +	AC_DEFINE([HAVE_RSA_METH_SET_FINISH], [1], [Emulate AC_CHECK_FUNCS since these are defined as macros])
> +	AC_DEFINE([HAVE_RSA_METH_SET0_APP_DATA], [1], [Emulate AC_CHECK_FUNCS since these are defined as macros])
> +	AC_DEFINE([HAVE_RSA_METH_GET0_APP_DATA], [1], [Emulate AC_CHECK_FUNCS since these are defined as macros])
> +	AC_DEFINE([HAVE_EC_GROUP_ORDER_BITS], [1], [Emulate AC_CHECK_FUNCS since these are defined as macros])
> +	
> +	have_crypto_aead_modes="yes"
> +	have_crypto="yes"
> +
> +	if test "${enable_wolfssl_options_h}" = "yes"; then
> +		AC_DEFINE([EXTERNAL_OPTS_OPENVPN], [1], [Include options.h from wolfSSL library])
> +	else
> +		AC_DEFINE([WOLFSSL_USER_SETTINGS], [1], [Use custom user_settings.h file for wolfSSL library])
> +	fi
> +	
> +	WOLFSSL_CFLAGS="${WOLFSSL_CFLAGS} -I${wolfssldir}"
> +	CFLAGS="${WOLFSSL_CFLAGS} ${CFLAGS}"
> +	LIBS="${WOLFSSL_LIBS} ${LIBS}"
> +	
> +	AC_DEFINE([ENABLE_CRYPTO_WOLFSSL], [1], [Use wolfSSL crypto library])
> +	AC_DEFINE([ENABLE_CRYPTO_OPENSSL], [1], [Use wolfSSL openssl compatibility layer])
> +	CRYPTO_CFLAGS="${WOLFSSL_CFLAGS}"
> +	CRYPTO_LIBS="${WOLFSSL_LIBS}"
>   else
>   	AC_MSG_ERROR([Invalid crypto library: ${with_crypto_library}])
>   fi
> diff --git a/src/openvpn/syshead.h b/src/openvpn/syshead.h
> index cafe4719..78e434ab 100644
> --- a/src/openvpn/syshead.h
> +++ b/src/openvpn/syshead.h
> @@ -587,7 +587,8 @@ socket_defined(const socket_descriptor_t sd)
>   /*
>    * Do we have CryptoAPI capability?
>    */
> -#if defined(_WIN32) && defined(ENABLE_CRYPTO_OPENSSL)
> +#if defined(_WIN32) && defined(ENABLE_CRYPTO_OPENSSL) && \
> +        !defined(ENABLE_CRYPTO_WOLFSSL)
>   #define ENABLE_CRYPTOAPI
>   #endif
>
Arne Schwabe July 22, 2020, 3:37 a.m. UTC | #2
Am 15.07.20 um 10:26 schrieb Juliusz Sosinowicz:
> Hi Everyone,
> 
> do you have an update on the latest patch I sent? There have been
> updates to wolfSSL to fix the remaining issues brought up last time.
>

Yes. I looked at this today in the expectation that I just compile test,
do a few quick tests and the ACK+merge it:

However during our preperation for the next OpenVPN release, we
reevaluated the minimum OpenSSL version and decided that OpenSSL 1.0.2
is our minimum target for the next release and removed the OpenSSL 1.0.1
compatibility defines. I was not aware that WolfSSL depended on the
compatibility to 1.0.1 but rather surprised since we added all the tests
compatibility in autoconf that made the OpenSSL 1.1.0+ API checks also
work for WolfSSL. We also removed the option to compile OpenVPN without
AEAD support and since WolfSSL supports TLS 1.3, I also did not expect
that this would be problematic for WolfSSL.


The missing functions that I can see quickly are:

SSL_CTX_set1_curves/SSL_CTX_set1_groups
SSL_CTX_get0_certificate
X509_get0_notBefore
X509_get0_notAfter
SSL_CTX_set_ecdh_auto (Would not be need if WolfSSL declared >= 1.1.0
version)
CRYPTO_memcmp

Also EVP_CIPH_FLAG_AEAD_CIPHER was undefined. It looks that in the older
version/patch the use of the define was ifdef'ed under the assumption
that support of AEAD implies existence of the macro, which is seems not
to have been true in the case of WolfSSL.

None of the offending functions looks particularly bad. The get0 are
just the more modern name of older identical OpenSSL version. The set
groups is probably already somehow support but not exposed and I would
be surprised if a constant time memcmp does not already exist in WolfSSL.

Reverting the patch that removed 1.0.1 feel like a bad option at this
point and will also raise (rightfully) eyebrows and questions.

Arne
Juliusz Sosinowicz July 22, 2020, 4:02 a.m. UTC | #3
Hi Arne,

thank you for your feedback. I tested the patch on the latest master 
version at the time of writing and it looks like these requirements were 
added in the last week which is why I wasn't able to address them 
before.I will look into the new issues and get back to you when they are 
fixed.

I agree that most of these functions only require exposing existing 
functionality on our side.

Sincerely
Juliusz

On 22/07/2020 15:37, Arne Schwabe wrote:
> Am 15.07.20 um 10:26 schrieb Juliusz Sosinowicz:
>> Hi Everyone,
>>
>> do you have an update on the latest patch I sent? There have been
>> updates to wolfSSL to fix the remaining issues brought up last time.
>>
> Yes. I looked at this today in the expectation that I just compile test,
> do a few quick tests and the ACK+merge it:
>
> However during our preperation for the next OpenVPN release, we
> reevaluated the minimum OpenSSL version and decided that OpenSSL 1.0.2
> is our minimum target for the next release and removed the OpenSSL 1.0.1
> compatibility defines. I was not aware that WolfSSL depended on the
> compatibility to 1.0.1 but rather surprised since we added all the tests
> compatibility in autoconf that made the OpenSSL 1.1.0+ API checks also
> work for WolfSSL. We also removed the option to compile OpenVPN without
> AEAD support and since WolfSSL supports TLS 1.3, I also did not expect
> that this would be problematic for WolfSSL.
>
>
> The missing functions that I can see quickly are:
>
> SSL_CTX_set1_curves/SSL_CTX_set1_groups
> SSL_CTX_get0_certificate
> X509_get0_notBefore
> X509_get0_notAfter
> SSL_CTX_set_ecdh_auto (Would not be need if WolfSSL declared >= 1.1.0
> version)
> CRYPTO_memcmp
>
> Also EVP_CIPH_FLAG_AEAD_CIPHER was undefined. It looks that in the older
> version/patch the use of the define was ifdef'ed under the assumption
> that support of AEAD implies existence of the macro, which is seems not
> to have been true in the case of WolfSSL.
>
> None of the offending functions looks particularly bad. The get0 are
> just the more modern name of older identical OpenSSL version. The set
> groups is probably already somehow support but not exposed and I would
> be surprised if a constant time memcmp does not already exist in WolfSSL.
>
> Reverting the patch that removed 1.0.1 feel like a bad option at this
> point and will also raise (rightfully) eyebrows and questions.
>
> Arne
>
>
Arne Schwabe Sept. 10, 2020, 12:18 a.m. UTC | #4
Am 22.07.20 um 16:02 schrieb Juliusz Sosinowicz:
> Hi Arne,
> 
> thank you for your feedback. I tested the patch on the latest master
> version at the time of writing and it looks like these requirements were
> added in the last week which is why I wasn't able to address them
> before.I will look into the new issues and get back to you when they are
> fixed.
> 
> I agree that most of these functions only require exposing existing
> functionality on our side.

We already progressed to OpenVPN 2.5-beta4 now. I think it is fair to
say that WolfSSL missed the window to be included in 2.5.0. And seeing
that these rather simple fixes take now over 1,5months does not exactly
inspire confidence that WolfSSL is committed to maintaining OpenVPN support.

Arne
Juliusz Sosinowicz Sept. 10, 2020, 2:11 a.m. UTC | #5
Hi Arne,

I understand your concern and apologize for the delay. We have been busy 
with the release of wolfSSL 4.5.0. I will make sure that the fixes 
necessary for OpenVPN support will be prioritized.

Sincerely
Juliusz

On 10/09/2020 12:18, Arne Schwabe wrote:
> Am 22.07.20 um 16:02 schrieb Juliusz Sosinowicz:
>> Hi Arne,
>>
>> thank you for your feedback. I tested the patch on the latest master
>> version at the time of writing and it looks like these requirements were
>> added in the last week which is why I wasn't able to address them
>> before.I will look into the new issues and get back to you when they are
>> fixed.
>>
>> I agree that most of these functions only require exposing existing
>> functionality on our side.
> We already progressed to OpenVPN 2.5-beta4 now. I think it is fair to
> say that WolfSSL missed the window to be included in 2.5.0. And seeing
> that these rather simple fixes take now over 1,5months does not exactly
> inspire confidence that WolfSSL is committed to maintaining OpenVPN support.
>
> Arne
>
>
Arne Schwabe Sept. 10, 2020, 2:16 a.m. UTC | #6
Am 10.09.20 um 14:11 schrieb Juliusz Sosinowicz:
> Hi Arne,
> 
> I understand your concern and apologize for the delay. We have been busy
> with the release of wolfSSL 4.5.0. I will make sure that the fixes
> necessary for OpenVPN support will be prioritized.
> 
> Sincerely
> Juliusz

I think the best way forward is to include wolfSSL support into OpenVPN
master now and if we have proper a proper support of wolfSSL that is
kept up to from your side then it will be part of the next release. And
otherwise we remove the support before the next release. That should our
concerns of wanting to see ongoing support and also your concern of it
not being included.

Arne
David Sommerseth Sept. 11, 2020, 2:29 a.m. UTC | #7
On 10/09/2020 14:16, Arne Schwabe wrote:
> Am 10.09.20 um 14:11 schrieb Juliusz Sosinowicz:
>> Hi Arne,
>>
>> I understand your concern and apologize for the delay. We have been busy
>> with the release of wolfSSL 4.5.0. I will make sure that the fixes
>> necessary for OpenVPN support will be prioritized.
>>
>> Sincerely
>> Juliusz
> 
> I think the best way forward is to include wolfSSL support into OpenVPN
> master now and if we have proper a proper support of wolfSSL that is
> kept up to from your side then it will be part of the next release. And
> otherwise we remove the support before the next release. That should our
> concerns of wanting to see ongoing support and also your concern of it
> not being included.

I completely agree.  This makes a lot of sense and is a reasonable way forward.
Juliusz Sosinowicz Sept. 15, 2020, 11:45 p.m. UTC | #8
Hi Arne,

a quick update. A PR is now open in wolfSSL with fixes for OpenVPN master.

Sincerely
Juliusz

On 10/09/2020 14:16, Arne Schwabe wrote:
> Am 10.09.20 um 14:11 schrieb Juliusz Sosinowicz:
>> Hi Arne,
>>
>> I understand your concern and apologize for the delay. We have been busy
>> with the release of wolfSSL 4.5.0. I will make sure that the fixes
>> necessary for OpenVPN support will be prioritized.
>>
>> Sincerely
>> Juliusz
> I think the best way forward is to include wolfSSL support into OpenVPN
> master now and if we have proper a proper support of wolfSSL that is
> kept up to from your side then it will be part of the next release. And
> otherwise we remove the support before the next release. That should our
> concerns of wanting to see ongoing support and also your concern of it
> not being included.
>
> Arne
>
Arne Schwabe Sept. 16, 2020, 12:05 p.m. UTC | #9
Am 16.09.20 um 11:45 schrieb Juliusz Sosinowicz:
> Hi Arne,
> 
> a quick update. A PR is now open in wolfSSL with fixes for OpenVPN master.

This is the version that I could actually take a deeper look at, so here
are my results. It generally works but there seems some loose ends:


I am still seeing this warning:


2020-09-16 23:20:14 WARNING: 'auth' is used inconsistently, local='auth
SHA', remote='auth SHA1'

Are you internally calling SHA1 just SHA and are also returned that as
name when querying for the name? And do the other SHA variant also just
return SHA?


This snippet in the configure.ac looks strange:

	if test -n "${WOLFSSL_DIR}"; then
		wolfssldir="${WOLFSSL_DIR}"
	else
		wolfssldir="/usr/local/include/wolfssl"
	fi

I am not sure hardcoding a /usr/local path is something we want/allow.
The people better at autoconf might have a better idea on this.

	have_crypto_aead_modes="yes"
	have_crypto="yes"

While the have_crypto_aead removal is a rather new removal, the
have_crypto removal happened over 4 years ago (31b0bebe). I think the
configure.ac should be cleaned up a bit more.


--tls-version-max 1.2 option is ignored.

--tls-version-min 1.3 against a (OpenSSL) server with --tls-version-max
1.2 results in:

2020-09-16 23:45:26 OpenSSL: Please supply a buffer for error string
2020-09-16 23:45:26 OpenSSL: Please supply a buffer for error string

(A quick fix with just trying to do a malloc of a buffer that leaks
memory transformed this in the also useless message OpenSSL: unknown
error number)

openvpn --show-tls does not work at all


Setting tls-ciphersuites results in (on the server side for the TLS 1.2
max server):

2020-09-16 23:54:22 us=503265 79.229.32.216:57019 TLS error: The server
has no TLS ciphersuites in common with the client. Your --tls-cipher
setting might be too restrictive.

I can also set TLS 1.3 cipher to tls-cipher. The design of TLS 1.3
ciphersuites and 1.0-1.2 cipher suites using different command is an
artificat of OpenSSL's behaviour but basically setting using
tls-cipher/tls-ciphersuites in the way the were intended seems to break
wolfSSL.

Loading the ed448 cert I have resulted in:

2020-09-16 23:58:28 OpenSSL: Please supply a buffer for error string

again.


--tls-groups meinekurve does not give me an error. So this option is
probably also ignored.

I am not expecting you test all the zillion options that OpenVPN has but
at least testing the TLS related option would be good. And what I am
currently seeing is not really a good coverage/buggy.

Even if some of the option might be a good option for support in
WolfSSL, we need to document this and/or your API needs to throw
reaonable errors.


Same notes since I ran WolfSSL also on my own development that includes
a few patches already sent to the mailing list but not merged:


This definition in WolfSSL:

wolfssl/openssl/ssl.h:#define SSL_export_keying_material(...) 0


This just breaks TLS EKM as WolfSSL pretensd to be able to do keying
material export but then cannot really do it. The patches to use TLS EKM
are currently not in master but will be definitively added until 2.6.

The macro have_export_keying_material="yes"  currently also missing in
the wolfssl configure.ac section but if enabling it, it just breaks:

=2020-09-16 23:31:17 TLS Error: Keying material export failed
202=0-09-16 23:31:17 TLS Error: generate_key_expansion failed

The "allow to work in FIPS mode" patch also breaks for the OpenSSL 1.0.2
code path:

    EVP_MD_CTX_set_flags(&ctx_init, EVP_MD_CTX_FLAG_NON_FIPS_ALLOW);

 error: use of undeclared identifier 'EVP_MD_CTX_FLAG_NON_FIPS_ALLOW'
 warning: implicit declaration of function 'EVP_MD_CTX_set_flags' is
invalid in C99

I am surprised you are targeting OpenSSL < 1.1.0 API. We will probably
drop OpenSSL 1.0.2 support from our code base as soon as we drop RHEL7
support. The 1.1.0+ code path in that patch uses the
EVP_PKEY_derive_*/EVP_PKEY_CTX_set_tls1_prf functions and those will be
needed then.

Arne
David Sommerseth Sept. 16, 2020, 12:58 p.m. UTC | #10
On 17/09/2020 00:05, Arne Schwabe wrote:
> This snippet in the configure.ac looks strange:
> 
> 	if test -n "${WOLFSSL_DIR}"; then
> 		wolfssldir="${WOLFSSL_DIR}"
> 	else
> 		wolfssldir="/usr/local/include/wolfssl"
> 	fi
> 
> I am not sure hardcoding a /usr/local path is something we want/allow.
> The people better at autoconf might have a better idea on this.

I'll bite on this one.

You seem to install wolfssl.pc in an appropriate directory, so it should
really pull the default path using PKG_CHECK_MODULES instead.  Having
overrides. like we do with OpenSSL (with OPENSSL_LIBS and OPENSSL_CFLAGS), is
fine.

The main challenge with the pkg-config is that it must use the same directory
on the system as the rest of the development packages uses.  This is usually
not an issue for developers using a distro package of the library; these
packages install all these pkg-config files in the appropriate directory.  The
challenge is more for those compiling and installing unpackaged versions of
the library; which is where the WOLFSSL_LIBS and WOLFSSL_CFLAGS comes into play.
Juliusz Sosinowicz Sept. 17, 2020, 5:50 a.m. UTC | #11
Hi Arne,

thank you for your extensive review of OpenVPN with wolfSSL.

On 17/09/2020 00:05, Arne Schwabe wrote:
> ...
> I am still seeing this warning:
>
>
> 2020-09-16 23:20:14 WARNING: 'auth' is used inconsistently, local='auth
> SHA', remote='auth SHA1'
>
> Are you internally calling SHA1 just SHA and are also returned that as
> name when querying for the name? And do the other SHA variant also just
> return SHA?
Could you describe how you generated this warning? Looking into our 
sources, we do call SHA1 just SHA in wolfSSL. Other variants have names 
in the format of SHA<hash size>.
> This snippet in the configure.ac looks strange:
>
> 	if test -n "${WOLFSSL_DIR}"; then
> 		wolfssldir="${WOLFSSL_DIR}"
> 	else
> 		wolfssldir="/usr/local/include/wolfssl"
> 	fi
>
> I am not sure hardcoding a /usr/local path is something we want/allow.
> The people better at autoconf might have a better idea on this.
Our default installation path is /usr/local/include which is why we set 
it as the default path in projects that use wolfSSL. Additionally, 
adding /usr/local/include/wolfssl to the include path allows including 
wolfSSL without changing *.c and *.h files. I'll look into David 
Sommerseth's suggestion of using pkg-config to get the path and see if 
it would be possible to append wolfssl to the path.
> ...
>
> I am surprised you are targeting OpenSSL < 1.1.0 API. We will probably
> drop OpenSSL 1.0.2 support from our code base as soon as we drop RHEL7
> support. The 1.1.0+ code path in that patch uses the
> EVP_PKEY_derive_*/EVP_PKEY_CTX_set_tls1_prf functions and those will be
> needed then.
>
I think that for now we will target OpenSSL < 1.1.0 API. Once other 
issues have been resolved we will start moving to OpenSSL >= 1.1.0 APIs.

I am still in the process of going through your report but I can 
reproduce most of the other issues and have found some additional ones 
as well. I have closed the PR for now until your comments are resolved 
and will re-open to include all fixes in one PR.

Sincerely
Juliusz
Arne Schwabe Sept. 17, 2020, 5:52 a.m. UTC | #12
Am 17.09.20 um 17:50 schrieb Juliusz Sosinowicz:
> Could you describe how you generated this warning? Looking into our
> sources, we do call SHA1 just SHA in wolfSSL. Other variants have names
> in the format of SHA<hash size>.

Just connecting to a server.

Arne
Juliusz Sosinowicz Nov. 19, 2020, 1:23 a.m. UTC | #13
Hi Arne,

some time has passed and I was able to address most of your comments in 
my branch 
https://github.com/julek-wolfssl/wolfssl/tree/openvpn-2.5-missing-stuff

To summarize what has been done regarding your comments:

  * SHA1 was indeed being called SHA in wolfSSL. I changed this in favor
    of just using SHA1.
  * in configure.ac I used David Sommerseth's suggestion to use
    PKG_CHECK_MODULES to get the wolfSSL installation directory.
  * setting tls min and max is currently not working in the branch that
    I linked above but we have a big compatibility layer PR pending that
    appears to fix these issues. Once it is merged I'll revisit this
    issue and make sure it is solved.
  * show-tls is fixed but it also relies on the PR I mentioned earlier.
    After that is merged this should be solved.
  * tls-ciphersuites and tls-cipher appears to be working in general.
    Should wolfSSL reject the specified cipher if for example a TLS 1.3
    cipher is set using --tls-cipher?
  * unfortunately wolfSSL does not support ed448 certificates.
  * tls-groups now checks the validity of the passed in curves
  * since OpenVPN will make use TLS EKM, exporting keying material has
    been implemented in wolfSSL.
  * I haven't tested OpenVPN with the FIPS mode patch so that issue is
    still pending. Once I get a chance to test it I will also change
    wolfSSL to target 1.1.0+ API

Thanks for your patience!

Sincerely
Juliusz

On 17/09/2020 00:05, Arne Schwabe wrote:
> Am 16.09.20 um 11:45 schrieb Juliusz Sosinowicz:
>> Hi Arne,
>>
>> a quick update. A PR is now open in wolfSSL with fixes for OpenVPN master.
> This is the version that I could actually take a deeper look at, so here
> are my results. It generally works but there seems some loose ends:
>
>
> I am still seeing this warning:
>
>
> 2020-09-16 23:20:14 WARNING: 'auth' is used inconsistently, local='auth
> SHA', remote='auth SHA1'
>
> Are you internally calling SHA1 just SHA and are also returned that as
> name when querying for the name? And do the other SHA variant also just
> return SHA?
>
>
> This snippet in the configure.ac looks strange:
>
> 	if test -n "${WOLFSSL_DIR}"; then
> 		wolfssldir="${WOLFSSL_DIR}"
> 	else
> 		wolfssldir="/usr/local/include/wolfssl"
> 	fi
>
> I am not sure hardcoding a /usr/local path is something we want/allow.
> The people better at autoconf might have a better idea on this.
>
> 	have_crypto_aead_modes="yes"
> 	have_crypto="yes"
>
> While the have_crypto_aead removal is a rather new removal, the
> have_crypto removal happened over 4 years ago (31b0bebe). I think the
> configure.ac should be cleaned up a bit more.
>
>
> --tls-version-max 1.2 option is ignored.
>
> --tls-version-min 1.3 against a (OpenSSL) server with --tls-version-max
> 1.2 results in:
>
> 2020-09-16 23:45:26 OpenSSL: Please supply a buffer for error string
> 2020-09-16 23:45:26 OpenSSL: Please supply a buffer for error string
>
> (A quick fix with just trying to do a malloc of a buffer that leaks
> memory transformed this in the also useless message OpenSSL: unknown
> error number)
>
> openvpn --show-tls does not work at all
>
>
> Setting tls-ciphersuites results in (on the server side for the TLS 1.2
> max server):
>
> 2020-09-16 23:54:22 us=503265 79.229.32.216:57019 TLS error: The server
> has no TLS ciphersuites in common with the client. Your --tls-cipher
> setting might be too restrictive.
>
> I can also set TLS 1.3 cipher to tls-cipher. The design of TLS 1.3
> ciphersuites and 1.0-1.2 cipher suites using different command is an
> artificat of OpenSSL's behaviour but basically setting using
> tls-cipher/tls-ciphersuites in the way the were intended seems to break
> wolfSSL.
>
> Loading the ed448 cert I have resulted in:
>
> 2020-09-16 23:58:28 OpenSSL: Please supply a buffer for error string
>
> again.
>
>
> --tls-groups meinekurve does not give me an error. So this option is
> probably also ignored.
>
> I am not expecting you test all the zillion options that OpenVPN has but
> at least testing the TLS related option would be good. And what I am
> currently seeing is not really a good coverage/buggy.
>
> Even if some of the option might be a good option for support in
> WolfSSL, we need to document this and/or your API needs to throw
> reaonable errors.
>
>
> Same notes since I ran WolfSSL also on my own development that includes
> a few patches already sent to the mailing list but not merged:
>
>
> This definition in WolfSSL:
>
> wolfssl/openssl/ssl.h:#define SSL_export_keying_material(...) 0
>
>
> This just breaks TLS EKM as WolfSSL pretensd to be able to do keying
> material export but then cannot really do it. The patches to use TLS EKM
> are currently not in master but will be definitively added until 2.6.
>
> The macro have_export_keying_material="yes"  currently also missing in
> the wolfssl configure.ac section but if enabling it, it just breaks:
>
> =2020-09-16 23:31:17 TLS Error: Keying material export failed
> 202=0-09-16 23:31:17 TLS Error: generate_key_expansion failed
>
> The "allow to work in FIPS mode" patch also breaks for the OpenSSL 1.0.2
> code path:
>
>      EVP_MD_CTX_set_flags(&ctx_init, EVP_MD_CTX_FLAG_NON_FIPS_ALLOW);
>
>   error: use of undeclared identifier 'EVP_MD_CTX_FLAG_NON_FIPS_ALLOW'
>   warning: implicit declaration of function 'EVP_MD_CTX_set_flags' is
> invalid in C99
>
> I am surprised you are targeting OpenSSL < 1.1.0 API. We will probably
> drop OpenSSL 1.0.2 support from our code base as soon as we drop RHEL7
> support. The 1.1.0+ code path in that patch uses the
> EVP_PKEY_derive_*/EVP_PKEY_CTX_set_tls1_prf functions and those will be
> needed then.
>
> Arne
>
<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <p>Hi Arne,</p>
    <p>some time has passed and I was able to address most of your
      comments in my branch
      <a class="moz-txt-link-freetext" href="https://github.com/julek-wolfssl/wolfssl/tree/openvpn-2.5-missing-stuff">https://github.com/julek-wolfssl/wolfssl/tree/openvpn-2.5-missing-stuff</a></p>
    <p>To summarize what has been done regarding your comments:</p>
    <ul>
      <li>SHA1 was indeed being called SHA in wolfSSL. I changed this in
        favor of just using SHA1.<br>
      </li>
      <li>in configure.ac I used David Sommerseth's suggestion to use
        PKG_CHECK_MODULES to get the wolfSSL installation directory.</li>
      <li>setting tls min and max is currently not working in the branch
        that I linked above but we have a big compatibility layer PR
        pending that appears to fix these issues. Once it is merged I'll
        revisit this issue and make sure it is solved.</li>
      <li>show-tls is fixed but it also relies on the PR I mentioned
        earlier. After that is merged this should be solved.</li>
      <li>tls-ciphersuites and tls-cipher appears to be working in
        general. Should wolfSSL reject the specified cipher if for
        example a TLS 1.3 cipher is set using --tls-cipher?</li>
      <li>unfortunately wolfSSL does not support ed448 certificates.</li>
      <li>tls-groups now checks the validity of the passed in curves</li>
      <li>since OpenVPN will make use TLS EKM, exporting keying material
        has been implemented in wolfSSL.</li>
      <li>I haven't tested OpenVPN with the FIPS mode patch so that
        issue is still pending. Once I get a chance to test it I will
        also change wolfSSL to target 1.1.0+ API</li>
    </ul>
    <p>Thanks for your patience!</p>
    <p>Sincerely<br>
      Juliusz<br>
    </p>
    <div class="moz-cite-prefix">On 17/09/2020 00:05, Arne Schwabe
      wrote:<br>
    </div>
    <blockquote type="cite"
      cite="mid:8e766bf2-a64e-63de-c69d-e899d2a11165@rfc2549.org">
      <pre class="moz-quote-pre" wrap="">Am 16.09.20 um 11:45 schrieb Juliusz Sosinowicz:
</pre>
      <blockquote type="cite">
        <pre class="moz-quote-pre" wrap="">Hi Arne,

a quick update. A PR is now open in wolfSSL with fixes for OpenVPN master.
</pre>
      </blockquote>
      <pre class="moz-quote-pre" wrap="">
This is the version that I could actually take a deeper look at, so here
are my results. It generally works but there seems some loose ends:


I am still seeing this warning:


2020-09-16 23:20:14 WARNING: 'auth' is used inconsistently, local='auth
SHA', remote='auth SHA1'

Are you internally calling SHA1 just SHA and are also returned that as
name when querying for the name? And do the other SHA variant also just
return SHA?


This snippet in the configure.ac looks strange:

	if test -n "${WOLFSSL_DIR}"; then
		wolfssldir="${WOLFSSL_DIR}"
	else
		wolfssldir="/usr/local/include/wolfssl"
	fi

I am not sure hardcoding a /usr/local path is something we want/allow.
The people better at autoconf might have a better idea on this.

	have_crypto_aead_modes="yes"
	have_crypto="yes"

While the have_crypto_aead removal is a rather new removal, the
have_crypto removal happened over 4 years ago (31b0bebe). I think the
configure.ac should be cleaned up a bit more.


--tls-version-max 1.2 option is ignored.

--tls-version-min 1.3 against a (OpenSSL) server with --tls-version-max
1.2 results in:

2020-09-16 23:45:26 OpenSSL: Please supply a buffer for error string
2020-09-16 23:45:26 OpenSSL: Please supply a buffer for error string

(A quick fix with just trying to do a malloc of a buffer that leaks
memory transformed this in the also useless message OpenSSL: unknown
error number)

openvpn --show-tls does not work at all


Setting tls-ciphersuites results in (on the server side for the TLS 1.2
max server):

2020-09-16 23:54:22 us=503265 79.229.32.216:57019 TLS error: The server
has no TLS ciphersuites in common with the client. Your --tls-cipher
setting might be too restrictive.

I can also set TLS 1.3 cipher to tls-cipher. The design of TLS 1.3
ciphersuites and 1.0-1.2 cipher suites using different command is an
artificat of OpenSSL's behaviour but basically setting using
tls-cipher/tls-ciphersuites in the way the were intended seems to break
wolfSSL.

Loading the ed448 cert I have resulted in:

2020-09-16 23:58:28 OpenSSL: Please supply a buffer for error string

again.


--tls-groups meinekurve does not give me an error. So this option is
probably also ignored.

I am not expecting you test all the zillion options that OpenVPN has but
at least testing the TLS related option would be good. And what I am
currently seeing is not really a good coverage/buggy.

Even if some of the option might be a good option for support in
WolfSSL, we need to document this and/or your API needs to throw
reaonable errors.


Same notes since I ran WolfSSL also on my own development that includes
a few patches already sent to the mailing list but not merged:


This definition in WolfSSL:

wolfssl/openssl/ssl.h:#define SSL_export_keying_material(...) 0


This just breaks TLS EKM as WolfSSL pretensd to be able to do keying
material export but then cannot really do it. The patches to use TLS EKM
are currently not in master but will be definitively added until 2.6.

The macro have_export_keying_material="yes"  currently also missing in
the wolfssl configure.ac section but if enabling it, it just breaks:

=2020-09-16 23:31:17 TLS Error: Keying material export failed
202=0-09-16 23:31:17 TLS Error: generate_key_expansion failed

The "allow to work in FIPS mode" patch also breaks for the OpenSSL 1.0.2
code path:

    EVP_MD_CTX_set_flags(&amp;ctx_init, EVP_MD_CTX_FLAG_NON_FIPS_ALLOW);

 error: use of undeclared identifier 'EVP_MD_CTX_FLAG_NON_FIPS_ALLOW'
 warning: implicit declaration of function 'EVP_MD_CTX_set_flags' is
invalid in C99

I am surprised you are targeting OpenSSL &lt; 1.1.0 API. We will probably
drop OpenSSL 1.0.2 support from our code base as soon as we drop RHEL7
support. The 1.1.0+ code path in that patch uses the
EVP_PKEY_derive_*/EVP_PKEY_CTX_set_tls1_prf functions and those will be
needed then.

Arne

</pre>
    </blockquote>
  </body>
</html>
Arne Schwabe Dec. 3, 2020, 1:22 a.m. UTC | #14
Am 19.11.20 um 13:23 schrieb Juliusz Sosinowicz:
> Hi Arne,
> 
> some time has passed and I was able to address most of your comments in
> my branch
> https://github.com/julek-wolfssl/wolfssl/tree/openvpn-2.5-missing-stuff
> 
> To summarize what has been done regarding your comments:
> 
>   * SHA1 was indeed being called SHA in wolfSSL. I changed this in favor
>     of just using SHA1.
>   * in configure.ac I used David Sommerseth's suggestion to use
>     PKG_CHECK_MODULES to get the wolfSSL installation directory.

Do you that new patch posted here? I don't see an updated patch.

>   * setting tls min and max is currently not working in the branch that
>     I linked above but we have a big compatibility layer PR pending that
>     appears to fix these issues. Once it is merged I'll revisit this
>     issue and make sure it is solved.
>   * show-tls is fixed but it also relies on the PR I mentioned earlier.
>     After that is merged this should be solved.
>   * tls-ciphersuites and tls-cipher appears to be working in general.
>     Should wolfSSL reject the specified cipher if for example a TLS 1.3
>     cipher is set using --tls-cipher?

Well that is a general question you have to answer yourself on OpenSSL
compatibility. I don't think this is just for OpenVPN.

>   * unfortunately wolfSSL does not support ed448 certificates.

That is not a show stopper. Mbed TLS does not support them either.

>   * tls-groups now checks the validity of the passed in curves
>   * since OpenVPN will make use TLS EKM, exporting keying material has
>     been implemented in wolfSSL.

Great!

>   * I haven't tested OpenVPN with the FIPS mode patch so that issue is
>     still pending. Once I get a chance to test it I will also change
>     wolfSSL to target 1.1.0+ API
> 
> Thanks for your patience!
> 

Hey I am trying to check on this. Since I haven't found the new patch. I
am trying to use it with the old one:

I am getting an error related to EKM:

./../../openvpn-git/src/openvpn/ssl_openssl.c:166:9: error: implicit
declaration of function 'wolfSSL_export_keying_material' is invalid in C99
      [-Werror,-Wimplicit-function-declaration]
    if (SSL_export_keying_material(ssl, ekm, ekm_size, label,


So I tried ./configure --enable-openvpn --enable-keying-material for
WolfSSL but that failed during compile:

src/tls13.c:806:50: error: implicit conversion loses integer precision:
'size_t' (aka 'unsigned long') to 'word32' (aka 'unsigned int')
      [-Werror,-Wshorten-64-to-32]
            protocol, protocolLen, (byte*)label, labelLen,
                                                 ^~~~~~~~
src/tls13.c:812:38: error: implicit conversion loses integer precision:
'size_t' (aka 'unsigned long') to 'word32' (aka 'unsigned int')
      [-Werror,-Wshorten-64-to-32]
    ret = wc_Hash(hashType, context, contextLen, hashOut,
WC_MAX_DIGEST_SIZE);
          ~~~~~~~                    ^~~~~~~~~~
src/tls13.c:816:34: error: implicit conversion loses integer precision:
'size_t' (aka 'unsigned long') to 'word32' (aka 'unsigned int')
      [-Werror,-Wshorten-64-to-32]
    ret = HKDF_Expand_Label(out, outLen, firstExpand, hashLen,
          ~~~~~~~~~~~~~~~~~      ^~~~~~
  CC       tests/unit_test-unit.o
src/ssl.c:11526:61: error: implicit conversion loses integer precision:
'unsigned long' to 'word32' (aka 'unsigned int')
[-Werror,-Wshorten-64-to-32]
    word32 seedLen = !use_context ? SEED_LEN : SEED_LEN + 2 + contextLen;
           ~~~~~~~                             ~~~~~~~~~~~~~^~~~~~~~~~~~
src/ssl.c:11590:25: error: implicit conversion loses integer precision:
'size_t' (aka 'unsigned long') to 'word32' (aka 'unsigned int')
      [-Werror,-Wshorten-64-to-32]
    if (wc_PRF_TLS(out, outLen, ssl->arrays->masterSecret, SECRET_LEN,
        ~~~~~~~~~~      ^~~~~~
src/ssl.c:11591:27: error: implicit conversion loses integer precision:
'size_t' (aka 'unsigned long') to 'word32' (aka 'unsigned int')
      [-Werror,-Wshorten-64-to-32]
            (byte*)label, labelLen, seed, seedLen, IsAtLeastTLSv1_2(ssl),



I am also seeing another warning during the compilation:

../../../openvpn-git/src/openvpn/ssl_openssl.c:1559:55: warning:
incompatible pointer types passing 'int (const X509_NAME *const *, const
      X509_NAME *const *)' (aka 'int (const struct WOLFSSL_X509_NAME
*const *, const struct WOLFSSL_X509_NAME *const *)') to parameter of type
      'wolf_sk_compare_cb' (aka 'int (*)(const void *const *, const void
*const *)') [-Wincompatible-pointer-types]
                        cert_names = sk_X509_NAME_new(sk_x509_name_cmp);
                                                      ^~~~~~~~~~~~~~~~


Arne
Juliusz Sosinowicz Dec. 3, 2020, 2:32 a.m. UTC | #15
Hi Arne,

I didn't send a new patch yet because I only wanted to provide an update 
that progress is being made. I'm attaching an updated patch if you are 
interested.

I didn't get that error when compiling wolfSSL with the compile options 
you provided. Is it possible that you didn't run `autoreconf` after 
pulling in the latest commit in the branch but before running the 
configure script?

The warning is due to wolfSSL using a generic compare function 
definition with pointers to void as parameters.

Sincerely
Juliusz

On 03/12/2020 13:22, Arne Schwabe wrote:
> Am 19.11.20 um 13:23 schrieb Juliusz Sosinowicz:
>> Hi Arne,
>>
>> some time has passed and I was able to address most of your comments in
>> my branch
>> https://github.com/julek-wolfssl/wolfssl/tree/openvpn-2.5-missing-stuff
>>
>> To summarize what has been done regarding your comments:
>>
>>    * SHA1 was indeed being called SHA in wolfSSL. I changed this in favor
>>      of just using SHA1.
>>    * in configure.ac I used David Sommerseth's suggestion to use
>>      PKG_CHECK_MODULES to get the wolfSSL installation directory.
> Do you that new patch posted here? I don't see an updated patch.
>
>>    * setting tls min and max is currently not working in the branch that
>>      I linked above but we have a big compatibility layer PR pending that
>>      appears to fix these issues. Once it is merged I'll revisit this
>>      issue and make sure it is solved.
>>    * show-tls is fixed but it also relies on the PR I mentioned earlier.
>>      After that is merged this should be solved.
>>    * tls-ciphersuites and tls-cipher appears to be working in general.
>>      Should wolfSSL reject the specified cipher if for example a TLS 1.3
>>      cipher is set using --tls-cipher?
> Well that is a general question you have to answer yourself on OpenSSL
> compatibility. I don't think this is just for OpenVPN.
>
>>    * unfortunately wolfSSL does not support ed448 certificates.
> That is not a show stopper. Mbed TLS does not support them either.
>
>>    * tls-groups now checks the validity of the passed in curves
>>    * since OpenVPN will make use TLS EKM, exporting keying material has
>>      been implemented in wolfSSL.
> Great!
>
>>    * I haven't tested OpenVPN with the FIPS mode patch so that issue is
>>      still pending. Once I get a chance to test it I will also change
>>      wolfSSL to target 1.1.0+ API
>>
>> Thanks for your patience!
>>
> Hey I am trying to check on this. Since I haven't found the new patch. I
> am trying to use it with the old one:
>
> I am getting an error related to EKM:
>
> ./../../openvpn-git/src/openvpn/ssl_openssl.c:166:9: error: implicit
> declaration of function 'wolfSSL_export_keying_material' is invalid in C99
>        [-Werror,-Wimplicit-function-declaration]
>      if (SSL_export_keying_material(ssl, ekm, ekm_size, label,
>
>
> So I tried ./configure --enable-openvpn --enable-keying-material for
> WolfSSL but that failed during compile:
>
> src/tls13.c:806:50: error: implicit conversion loses integer precision:
> 'size_t' (aka 'unsigned long') to 'word32' (aka 'unsigned int')
>        [-Werror,-Wshorten-64-to-32]
>              protocol, protocolLen, (byte*)label, labelLen,
>                                                   ^~~~~~~~
> src/tls13.c:812:38: error: implicit conversion loses integer precision:
> 'size_t' (aka 'unsigned long') to 'word32' (aka 'unsigned int')
>        [-Werror,-Wshorten-64-to-32]
>      ret = wc_Hash(hashType, context, contextLen, hashOut,
> WC_MAX_DIGEST_SIZE);
>            ~~~~~~~                    ^~~~~~~~~~
> src/tls13.c:816:34: error: implicit conversion loses integer precision:
> 'size_t' (aka 'unsigned long') to 'word32' (aka 'unsigned int')
>        [-Werror,-Wshorten-64-to-32]
>      ret = HKDF_Expand_Label(out, outLen, firstExpand, hashLen,
>            ~~~~~~~~~~~~~~~~~      ^~~~~~
>    CC       tests/unit_test-unit.o
> src/ssl.c:11526:61: error: implicit conversion loses integer precision:
> 'unsigned long' to 'word32' (aka 'unsigned int')
> [-Werror,-Wshorten-64-to-32]
>      word32 seedLen = !use_context ? SEED_LEN : SEED_LEN + 2 + contextLen;
>             ~~~~~~~                             ~~~~~~~~~~~~~^~~~~~~~~~~~
> src/ssl.c:11590:25: error: implicit conversion loses integer precision:
> 'size_t' (aka 'unsigned long') to 'word32' (aka 'unsigned int')
>        [-Werror,-Wshorten-64-to-32]
>      if (wc_PRF_TLS(out, outLen, ssl->arrays->masterSecret, SECRET_LEN,
>          ~~~~~~~~~~      ^~~~~~
> src/ssl.c:11591:27: error: implicit conversion loses integer precision:
> 'size_t' (aka 'unsigned long') to 'word32' (aka 'unsigned int')
>        [-Werror,-Wshorten-64-to-32]
>              (byte*)label, labelLen, seed, seedLen, IsAtLeastTLSv1_2(ssl),
>
>
>
> I am also seeing another warning during the compilation:
>
> ../../../openvpn-git/src/openvpn/ssl_openssl.c:1559:55: warning:
> incompatible pointer types passing 'int (const X509_NAME *const *, const
>        X509_NAME *const *)' (aka 'int (const struct WOLFSSL_X509_NAME
> *const *, const struct WOLFSSL_X509_NAME *const *)') to parameter of type
>        'wolf_sk_compare_cb' (aka 'int (*)(const void *const *, const void
> *const *)') [-Wincompatible-pointer-types]
>                          cert_names = sk_X509_NAME_new(sk_x509_name_cmp);
>                                                        ^~~~~~~~~~~~~~~~
>
>
> Arne
From 7ee789ed7632d1eb43f0d461ab4e0801607e9031 Mon Sep 17 00:00:00 2001
From: Juliusz Sosinowicz <juliusz@wolfssl.com>
Date: Thu, 28 Nov 2019 19:10:44 +0100
Subject: [PATCH] Support for wolfSSL in OpenVPN

This patch adds support for wolfSSL in OpenVPN. Support is added by using wolfSSL's OpenSSL compatibility layer. Function calls are left unchanged and instead the OpenSSL includes point to wolfSSL headers and OpenVPN is linked against the wolfSSL library. The wolfSSL installation directory is detected using pkg-config.

As requested by OpenVPN maintainers, this patch does not include wolfssl/options.h on its own. By defining the macro EXTERNAL_OPTS_OPENVPN in the configure script wolfSSL will include wolfssl/options.h on its own (change added in https://github.com/wolfSSL/wolfssl/pull/2825). The patch adds an option `--disable-wolfssl-options-h` in case the user would like to supply their own settings file for wolfSSL.

wolfSSL:
Support added in: https://github.com/wolfSSL/wolfssl/pull/2503
```
git clone https://github.com/wolfSSL/wolfssl.git
cd wolfssl
./autogen.sh
./configure --enable-openvpn
make
sudo make install
```

OpenVPN:
```
autoreconf -i -v -f
./configure --with-crypto-library=wolfssl
make
make check
sudo make install
```

Signed-off-by: Juliusz Sosinowicz <juliusz@wolfssl.com>
---
 configure.ac          | 107 +++++++++++++++++++++++++++++++++++++++++-
 src/openvpn/syshead.h |   3 +-
 2 files changed, 107 insertions(+), 3 deletions(-)

diff --git a/configure.ac b/configure.ac
index 1ab8fe59d..96321a1e4 100644
--- a/configure.ac
+++ b/configure.ac
@@ -264,16 +264,23 @@ AC_ARG_WITH(
 
 AC_ARG_WITH(
 	[crypto-library],
-	[AS_HELP_STRING([--with-crypto-library=library], [build with the given crypto library, TYPE=openssl|mbedtls @<:@default=openssl@:>@])],
+	[AS_HELP_STRING([--with-crypto-library=library], [build with the given crypto library, TYPE=openssl|mbedtls|wolfssl @<:@default=openssl@:>@])],
 	[
 		case "${withval}" in
-			openssl|mbedtls) ;;
+			openssl|mbedtls|wolfssl) ;;
 			*) AC_MSG_ERROR([bad value ${withval} for --with-crypto-library]) ;;
 		esac
 	],
 	[with_crypto_library="openssl"]
 )
 
+AC_ARG_ENABLE(
+	[wolfssl-options-h],
+	[AS_HELP_STRING([--disable-wolfssl-options-h], [Disable including options.h in wolfSSL @<:@default=yes@:>@])],
+	,
+	[enable_wolfssl_options_h="yes"]
+)
+
 AC_ARG_VAR([PLUGINDIR], [Path of plug-in directory @<:@default=LIBDIR/openvpn/plugins@:>@])
 if test -n "${PLUGINDIR}"; then
 	plugindir="${PLUGINDIR}"
@@ -1019,6 +1026,102 @@ elif test "${with_crypto_library}" = "mbedtls"; then
 	AC_DEFINE([ENABLE_CRYPTO_MBEDTLS], [1], [Use mbed TLS library])
 	CRYPTO_CFLAGS="${MBEDTLS_CFLAGS}"
 	CRYPTO_LIBS="${MBEDTLS_LIBS}"
+
+elif test "${with_crypto_library}" = "wolfssl"; then
+	AC_ARG_VAR([WOLFSSL_CFLAGS], [C compiler flags for wolfssl. The include directory should
+								  contain the regular wolfSSL header files but also the 
+								  wolfSSL OpenSSL header files. Ex: -I/usr/local/include 
+								  -I/usr/local/include/wolfssl])
+	AC_ARG_VAR([WOLFSSL_LIBS], [linker flags for wolfssl])
+
+	saved_CFLAGS="${CFLAGS}"
+	saved_LIBS="${LIBS}"
+
+	if test -z "${WOLFSSL_CFLAGS}" -a -z "${WOLFSSL_LIBS}"; then
+		# if the user did not explicitly specify flags, try to autodetect
+		PKG_CHECK_MODULES(
+			[WOLFSSL],
+			[wolfssl],
+			[],
+			[AC_MSG_ERROR([Could not find wolfSSL.])]
+		)
+		PKG_CHECK_VAR(
+			[WOLFSSL_INCLUDEDIR], 
+			[wolfssl], 
+			[includedir], 
+			[],
+			[AC_MSG_ERROR([Could not find wolfSSL includedir variable.])]
+		)
+		WOLFSSL_CFLAGS="${WOLFSSL_CFLAGS} -I${WOLFSSL_INCLUDEDIR}/wolfssl"
+	fi
+	saved_CFLAGS="${CFLAGS}"
+	saved_LIBS="${LIBS}"
+	CFLAGS="${CFLAGS} ${WOLFSSL_CFLAGS}"
+	LIBS="${LIBS} ${WOLFSSL_LIBS}"
+
+	AC_CHECK_LIB(
+		[wolfssl],
+		[wolfSSL_Init],
+		[],
+		[AC_MSG_ERROR([Could not link wolfSSL library.])]
+	)
+	AC_CHECK_HEADER([wolfssl/options.h],,[AC_MSG_ERROR([wolfSSL header wolfssl/options.h not found!])])
+
+	AC_DEFINE([HAVE_HMAC_CTX_NEW], [1], [Emulate AC_CHECK_FUNCS since these are defined as macros])
+	AC_DEFINE([HAVE_HMAC_CTX_FREE], [1], [Emulate AC_CHECK_FUNCS since these are defined as macros])
+	AC_DEFINE([HAVE_HMAC_CTX_RESET], [1], [Emulate AC_CHECK_FUNCS since these are defined as macros])
+	AC_DEFINE([HAVE_EVP_MD_CTX_NEW], [1], [Emulate AC_CHECK_FUNCS since these are defined as macros])
+	AC_DEFINE([HAVE_EVP_MD_CTX_FREE], [1], [Emulate AC_CHECK_FUNCS since these are defined as macros])
+	AC_DEFINE([HAVE_EVP_MD_CTX_RESET], [1], [Emulate AC_CHECK_FUNCS since these are defined as macros])
+	AC_DEFINE([HAVE_EVP_CIPHER_CTX_RESET], [1], [Emulate AC_CHECK_FUNCS since these are defined as macros])
+	AC_DEFINE([HAVE_OPENSSL_VERSION], [1], [Emulate AC_CHECK_FUNCS since these are defined as macros])
+	AC_DEFINE([HAVE_SSL_CTX_GET_DEFAULT_PASSWD_CB], [1], [Emulate AC_CHECK_FUNCS since these are defined as macros])
+	AC_DEFINE([HAVE_SSL_CTX_GET_DEFAULT_PASSWD_CB_USERDATA], [1], [Emulate AC_CHECK_FUNCS since these are defined as macros])
+	AC_DEFINE([HAVE_SSL_CTX_SET_SECURITY_LEVEL], [1], [Emulate AC_CHECK_FUNCS since these are defined as macros])
+	AC_DEFINE([HAVE_X509_GET0_NOTBEFORE], [1], [Emulate AC_CHECK_FUNCS since these are defined as macros])
+	AC_DEFINE([HAVE_X509_GET0_NOTAFTER], [1], [Emulate AC_CHECK_FUNCS since these are defined as macros])
+	AC_DEFINE([HAVE_X509_GET0_PUBKEY], [1], [Emulate AC_CHECK_FUNCS since these are defined as macros])
+	AC_DEFINE([HAVE_X509_STORE_GET0_OBJECTS], [1], [Emulate AC_CHECK_FUNCS since these are defined as macros])
+	AC_DEFINE([HAVE_X509_OBJECT_FREE], [1], [Emulate AC_CHECK_FUNCS since these are defined as macros])
+	AC_DEFINE([HAVE_X509_OBJECT_GET_TYPE], [1], [Emulate AC_CHECK_FUNCS since these are defined as macros])
+	AC_DEFINE([HAVE_EVP_PKEY_ID], [1], [Emulate AC_CHECK_FUNCS since these are defined as macros])
+	AC_DEFINE([HAVE_EVP_PKEY_GET0_RSA], [1], [Emulate AC_CHECK_FUNCS since these are defined as macros])
+	AC_DEFINE([HAVE_EVP_PKEY_GET0_DSA], [1], [Emulate AC_CHECK_FUNCS since these are defined as macros])
+	AC_DEFINE([HAVE_EVP_PKEY_GET0_EC_KEY], [1], [Emulate AC_CHECK_FUNCS since these are defined as macros])
+	AC_DEFINE([HAVE_RSA_SET_FLAGS], [1], [Emulate AC_CHECK_FUNCS since these are defined as macros])
+	AC_DEFINE([HAVE_RSA_BITS], [1], [Emulate AC_CHECK_FUNCS since these are defined as macros])
+	AC_DEFINE([HAVE_RSA_GET0_KEY], [1], [Emulate AC_CHECK_FUNCS since these are defined as macros])
+	AC_DEFINE([HAVE_RSA_SET0_KEY], [1], [Emulate AC_CHECK_FUNCS since these are defined as macros])
+	AC_DEFINE([HAVE_DSA_GET0_PQG], [1], [Emulate AC_CHECK_FUNCS since these are defined as macros])
+	AC_DEFINE([HAVE_DSA_BITS], [1], [Emulate AC_CHECK_FUNCS since these are defined as macros])
+	AC_DEFINE([HAVE_RSA_METH_NEW], [1], [Emulate AC_CHECK_FUNCS since these are defined as macros])
+	AC_DEFINE([HAVE_RSA_METH_FREE], [1], [Emulate AC_CHECK_FUNCS since these are defined as macros])
+	AC_DEFINE([HAVE_RSA_METH_SET_PUB_ENC], [1], [Emulate AC_CHECK_FUNCS since these are defined as macros])
+	AC_DEFINE([HAVE_RSA_METH_SET_PUB_DEC], [1], [Emulate AC_CHECK_FUNCS since these are defined as macros])
+	AC_DEFINE([HAVE_RSA_METH_SET_PRIV_ENC], [1], [Emulate AC_CHECK_FUNCS since these are defined as macros])
+	AC_DEFINE([HAVE_RSA_METH_SET_PRIV_DEC], [1], [Emulate AC_CHECK_FUNCS since these are defined as macros])
+	AC_DEFINE([HAVE_RSA_METH_SET_INIT], [1], [Emulate AC_CHECK_FUNCS since these are defined as macros])
+	AC_DEFINE([HAVE_RSA_METH_SET_SIGN], [1], [Emulate AC_CHECK_FUNCS since these are defined as macros])
+	AC_DEFINE([HAVE_RSA_METH_SET_FINISH], [1], [Emulate AC_CHECK_FUNCS since these are defined as macros])
+	AC_DEFINE([HAVE_RSA_METH_SET0_APP_DATA], [1], [Emulate AC_CHECK_FUNCS since these are defined as macros])
+	AC_DEFINE([HAVE_RSA_METH_GET0_APP_DATA], [1], [Emulate AC_CHECK_FUNCS since these are defined as macros])
+	AC_DEFINE([HAVE_EC_GROUP_ORDER_BITS], [1], [Emulate AC_CHECK_FUNCS since these are defined as macros])
+
+	if test "${enable_wolfssl_options_h}" = "yes"; then
+		AC_DEFINE([EXTERNAL_OPTS_OPENVPN], [1], [Include options.h from wolfSSL library])
+	else
+		AC_DEFINE([WOLFSSL_USER_SETTINGS], [1], [Use custom user_settings.h file for wolfSSL library])
+	fi
+	
+	have_export_keying_material="yes"
+	
+	CFLAGS="${saved_CFLAGS}"
+	LIBS="${saved_LIBS}"
+	
+	AC_DEFINE([ENABLE_CRYPTO_WOLFSSL], [1], [Use wolfSSL crypto library])
+	AC_DEFINE([ENABLE_CRYPTO_OPENSSL], [1], [Use wolfSSL openssl compatibility layer])
+	CRYPTO_CFLAGS="${WOLFSSL_CFLAGS}"
+	CRYPTO_LIBS="${WOLFSSL_LIBS}"
 else
 	AC_MSG_ERROR([Invalid crypto library: ${with_crypto_library}])
 fi
diff --git a/src/openvpn/syshead.h b/src/openvpn/syshead.h
index 2ad5afc20..a20de1f65 100644
--- a/src/openvpn/syshead.h
+++ b/src/openvpn/syshead.h
@@ -569,7 +569,8 @@ socket_defined(const socket_descriptor_t sd)
 /*
  * Do we have CryptoAPI capability?
  */
-#if defined(_WIN32) && defined(ENABLE_CRYPTO_OPENSSL)
+#if defined(_WIN32) && defined(ENABLE_CRYPTO_OPENSSL) && \
+        !defined(ENABLE_CRYPTO_WOLFSSL)
 #define ENABLE_CRYPTOAPI
 #endif
Arne Schwabe Dec. 3, 2020, 3:22 a.m. UTC | #16
Am 03.12.20 um 14:32 schrieb Juliusz Sosinowicz:
> Hi Arne,
> 
> I didn't send a new patch yet because I only wanted to provide an update
> that progress is being made. I'm attaching an updated patch if you are
> interested.
> 
> I didn't get that error when compiling wolfSSL with the compile options
> you provided. Is it possible that you didn't run `autoreconf` after
> pulling in the latest commit in the branch but before running the
> configure script?

Yes. The -Wshorten-64-to-32 might be Clang/LLVM specific or not enabled
on gcc by default.

> 
> The warning is due to wolfSSL using a generic compare function
> definition with pointers to void as parameters.

Yeah, it breaks -Werror which I normally use to compile OpenVPN.

Arne
Arne Schwabe Jan. 27, 2021, 8:07 a.m. UTC | #17
Am 27.01.21 um 18:25 schrieb Juliusz Sosinowicz:
> Hi Arne,
> 
> I believe I fixed the issues that you mentioned in your review of the
> patch for wolfSSL. I have sent a new patch tested on the latest master
> branch on OpenVPN along with the version of wolfSSL found in this pull
> request: https://github.com/wolfSSL/wolfssl/pull/3697 .
> 

Unfortunatel,y I am still not able to compile that branch on
macOS/clang. It seem wolfssl uses -Werror and this breaks it. On a quick
check I also don't see an option to disable this behaviour in configure.

The master branch compiles but that doesn't work for OpenVPN.

src/tls13.c:806:50: error: implicit conversion loses integer precision:
'size_t' (aka 'unsigned long') to 'word32' (aka 'unsigned int')
[-Werror,-Wshorten-64-to-32]
            protocol, protocolLen, (byte*)label, labelLen,
                                                 ^~~~~~~~
src/tls13.c:812:38: error: implicit conversion loses integer precision:
'size_t' (aka 'unsigned long') to 'word32' (aka 'unsigned int')
[-Werror,-Wshorten-64-to-32]
    ret = wc_Hash(hashType, context, contextLen, hashOut,
WC_MAX_DIGEST_SIZE);
          ~~~~~~~                    ^~~~~~~~~~
src/tls13.c:816:34: error: implicit conversion loses integer precision:
'size_t' (aka 'unsigned long') to 'word32' (aka 'unsigned int')
[-Werror,-Wshorten-64-to-32]
    ret = HKDF_Expand_Label(out, outLen, firstExpand, hashLen,
          ~~~~~~~~~~~~~~~~~      ^~~~~~
  CC       examples/server/testsuite_testsuite_test-server.o
  CC       testsuite/testsuite_test-testsuite.o
  CC       tests/unit_test-unit.o
3 errors generated.
make[2]: *** [src/libwolfssl_la-tls13.lo] Error 1
make[2]: *** Waiting for unfinished jobs....
src/ssl.c:11527:61: error: implicit conversion loses integer precision:
'unsigned long' to 'word32' (aka 'unsigned int')
[-Werror,-Wshorten-64-to-32]
    word32 seedLen = !use_context ? SEED_LEN : SEED_LEN + 2 + contextLen;
           ~~~~~~~                             ~~~~~~~~~~~~~^~~~~~~~~~~~
src/ssl.c:11591:25: error: implicit conversion loses integer precision:
'size_t' (aka 'unsigned long') to 'word32' (aka 'unsigned int')
[-Werror,-Wshorten-64-to-32]
    if (wc_PRF_TLS(out, outLen, ssl->arrays->masterSecret, SECRET_LEN,
        ~~~~~~~~~~      ^~~~~~
src/ssl.c:11592:27: error: implicit conversion loses integer precision:
'size_t' (aka 'unsigned long') to 'word32' (aka 'unsigned int')
[-Werror,-Wshorten-64-to-32]
            (byte*)label, labelLen, seed, seedLen, IsAtLeastTLSv1_2(ssl),
                          ^~~~~~~~
3 errors generated.
make[2]: *** [src/libwolfssl_la-ssl.lo] Error 1
make[1]: *** [all-recursive] Error 1
make: *** [all] Error 2
Time: 0h:00m:27s
Juliusz Sosinowicz Jan. 27, 2021, 10:59 p.m. UTC | #18
Hi Arne,

our CI tests caught that as well. I was able to fix it quickly but it 
looks like you were even quicker :D The latest version of the PR should 
be free from the implicit conversion errors.

Sincerely
Juliusz

On 27/01/2021 20:07, Arne Schwabe wrote:
> Am 27.01.21 um 18:25 schrieb Juliusz Sosinowicz:
>> Hi Arne,
>>
>> I believe I fixed the issues that you mentioned in your review of the
>> patch for wolfSSL. I have sent a new patch tested on the latest master
>> branch on OpenVPN along with the version of wolfSSL found in this pull
>> request: https://github.com/wolfSSL/wolfssl/pull/3697 .
>>
> Unfortunatel,y I am still not able to compile that branch on
> macOS/clang. It seem wolfssl uses -Werror and this breaks it. On a quick
> check I also don't see an option to disable this behaviour in configure.
>
> The master branch compiles but that doesn't work for OpenVPN.
>
> src/tls13.c:806:50: error: implicit conversion loses integer precision:
> 'size_t' (aka 'unsigned long') to 'word32' (aka 'unsigned int')
> [-Werror,-Wshorten-64-to-32]
>              protocol, protocolLen, (byte*)label, labelLen,
>                                                   ^~~~~~~~
> src/tls13.c:812:38: error: implicit conversion loses integer precision:
> 'size_t' (aka 'unsigned long') to 'word32' (aka 'unsigned int')
> [-Werror,-Wshorten-64-to-32]
>      ret = wc_Hash(hashType, context, contextLen, hashOut,
> WC_MAX_DIGEST_SIZE);
>            ~~~~~~~                    ^~~~~~~~~~
> src/tls13.c:816:34: error: implicit conversion loses integer precision:
> 'size_t' (aka 'unsigned long') to 'word32' (aka 'unsigned int')
> [-Werror,-Wshorten-64-to-32]
>      ret = HKDF_Expand_Label(out, outLen, firstExpand, hashLen,
>            ~~~~~~~~~~~~~~~~~      ^~~~~~
>    CC       examples/server/testsuite_testsuite_test-server.o
>    CC       testsuite/testsuite_test-testsuite.o
>    CC       tests/unit_test-unit.o
> 3 errors generated.
> make[2]: *** [src/libwolfssl_la-tls13.lo] Error 1
> make[2]: *** Waiting for unfinished jobs....
> src/ssl.c:11527:61: error: implicit conversion loses integer precision:
> 'unsigned long' to 'word32' (aka 'unsigned int')
> [-Werror,-Wshorten-64-to-32]
>      word32 seedLen = !use_context ? SEED_LEN : SEED_LEN + 2 + contextLen;
>             ~~~~~~~                             ~~~~~~~~~~~~~^~~~~~~~~~~~
> src/ssl.c:11591:25: error: implicit conversion loses integer precision:
> 'size_t' (aka 'unsigned long') to 'word32' (aka 'unsigned int')
> [-Werror,-Wshorten-64-to-32]
>      if (wc_PRF_TLS(out, outLen, ssl->arrays->masterSecret, SECRET_LEN,
>          ~~~~~~~~~~      ^~~~~~
> src/ssl.c:11592:27: error: implicit conversion loses integer precision:
> 'size_t' (aka 'unsigned long') to 'word32' (aka 'unsigned int')
> [-Werror,-Wshorten-64-to-32]
>              (byte*)label, labelLen, seed, seedLen, IsAtLeastTLSv1_2(ssl),
>                            ^~~~~~~~
> 3 errors generated.
> make[2]: *** [src/libwolfssl_la-ssl.lo] Error 1
> make[1]: *** [all-recursive] Error 1
> make: *** [all] Error 2
> Time: 0h:00m:27s
>
>
Juliusz Sosinowicz Feb. 15, 2021, 1:13 a.m. UTC | #19
Hi Arne,

the pull request has been merged to the wolfSSL master branch and will 
be included in the next wolfSSL release. Your issue has been resolved. 
Are able to try compiling again?

Sincerely
Juliusz

On 27/01/2021 20:07, Arne Schwabe wrote:
> Am 27.01.21 um 18:25 schrieb Juliusz Sosinowicz:
>> Hi Arne,
>>
>> I believe I fixed the issues that you mentioned in your review of the
>> patch for wolfSSL. I have sent a new patch tested on the latest master
>> branch on OpenVPN along with the version of wolfSSL found in this pull
>> request: https://github.com/wolfSSL/wolfssl/pull/3697 .
>>
> Unfortunatel,y I am still not able to compile that branch on
> macOS/clang. It seem wolfssl uses -Werror and this breaks it. On a quick
> check I also don't see an option to disable this behaviour in configure.
>
> The master branch compiles but that doesn't work for OpenVPN.
>
> src/tls13.c:806:50: error: implicit conversion loses integer precision:
> 'size_t' (aka 'unsigned long') to 'word32' (aka 'unsigned int')
> [-Werror,-Wshorten-64-to-32]
>              protocol, protocolLen, (byte*)label, labelLen,
>                                                   ^~~~~~~~
> src/tls13.c:812:38: error: implicit conversion loses integer precision:
> 'size_t' (aka 'unsigned long') to 'word32' (aka 'unsigned int')
> [-Werror,-Wshorten-64-to-32]
>      ret = wc_Hash(hashType, context, contextLen, hashOut,
> WC_MAX_DIGEST_SIZE);
>            ~~~~~~~                    ^~~~~~~~~~
> src/tls13.c:816:34: error: implicit conversion loses integer precision:
> 'size_t' (aka 'unsigned long') to 'word32' (aka 'unsigned int')
> [-Werror,-Wshorten-64-to-32]
>      ret = HKDF_Expand_Label(out, outLen, firstExpand, hashLen,
>            ~~~~~~~~~~~~~~~~~      ^~~~~~
>    CC       examples/server/testsuite_testsuite_test-server.o
>    CC       testsuite/testsuite_test-testsuite.o
>    CC       tests/unit_test-unit.o
> 3 errors generated.
> make[2]: *** [src/libwolfssl_la-tls13.lo] Error 1
> make[2]: *** Waiting for unfinished jobs....
> src/ssl.c:11527:61: error: implicit conversion loses integer precision:
> 'unsigned long' to 'word32' (aka 'unsigned int')
> [-Werror,-Wshorten-64-to-32]
>      word32 seedLen = !use_context ? SEED_LEN : SEED_LEN + 2 + contextLen;
>             ~~~~~~~                             ~~~~~~~~~~~~~^~~~~~~~~~~~
> src/ssl.c:11591:25: error: implicit conversion loses integer precision:
> 'size_t' (aka 'unsigned long') to 'word32' (aka 'unsigned int')
> [-Werror,-Wshorten-64-to-32]
>      if (wc_PRF_TLS(out, outLen, ssl->arrays->masterSecret, SECRET_LEN,
>          ~~~~~~~~~~      ^~~~~~
> src/ssl.c:11592:27: error: implicit conversion loses integer precision:
> 'size_t' (aka 'unsigned long') to 'word32' (aka 'unsigned int')
> [-Werror,-Wshorten-64-to-32]
>              (byte*)label, labelLen, seed, seedLen, IsAtLeastTLSv1_2(ssl),
>                            ^~~~~~~~
> 3 errors generated.
> make[2]: *** [src/libwolfssl_la-ssl.lo] Error 1
> make[1]: *** [all-recursive] Error 1
> make: *** [all] Error 2
> Time: 0h:00m:27s
>
>
Juliusz Sosinowicz Feb. 22, 2021, 4:28 a.m. UTC | #20
Hi Arne,

have you had any success in compiling OpenVPN with wolfSSL?

Sincerely
Juliusz

On 15/02/2021 13:13, Juliusz Sosinowicz wrote:
> Hi Arne,
>
> the pull request has been merged to the wolfSSL master branch and will 
> be included in the next wolfSSL release. Your issue has been resolved. 
> Are able to try compiling again?
>
> Sincerely
> Juliusz
>
> On 27/01/2021 20:07, Arne Schwabe wrote:
>> Am 27.01.21 um 18:25 schrieb Juliusz Sosinowicz:
>>> Hi Arne,
>>>
>>> I believe I fixed the issues that you mentioned in your review of the
>>> patch for wolfSSL. I have sent a new patch tested on the latest master
>>> branch on OpenVPN along with the version of wolfSSL found in this pull
>>> request: https://github.com/wolfSSL/wolfssl/pull/3697 .
>>>
>> Unfortunatel,y I am still not able to compile that branch on
>> macOS/clang. It seem wolfssl uses -Werror and this breaks it. On a quick
>> check I also don't see an option to disable this behaviour in configure.
>>
>> The master branch compiles but that doesn't work for OpenVPN.
>>
>> src/tls13.c:806:50: error: implicit conversion loses integer precision:
>> 'size_t' (aka 'unsigned long') to 'word32' (aka 'unsigned int')
>> [-Werror,-Wshorten-64-to-32]
>>              protocol, protocolLen, (byte*)label, labelLen,
>>                                                   ^~~~~~~~
>> src/tls13.c:812:38: error: implicit conversion loses integer precision:
>> 'size_t' (aka 'unsigned long') to 'word32' (aka 'unsigned int')
>> [-Werror,-Wshorten-64-to-32]
>>      ret = wc_Hash(hashType, context, contextLen, hashOut,
>> WC_MAX_DIGEST_SIZE);
>>            ~~~~~~~                    ^~~~~~~~~~
>> src/tls13.c:816:34: error: implicit conversion loses integer precision:
>> 'size_t' (aka 'unsigned long') to 'word32' (aka 'unsigned int')
>> [-Werror,-Wshorten-64-to-32]
>>      ret = HKDF_Expand_Label(out, outLen, firstExpand, hashLen,
>>            ~~~~~~~~~~~~~~~~~      ^~~~~~
>>    CC       examples/server/testsuite_testsuite_test-server.o
>>    CC       testsuite/testsuite_test-testsuite.o
>>    CC       tests/unit_test-unit.o
>> 3 errors generated.
>> make[2]: *** [src/libwolfssl_la-tls13.lo] Error 1
>> make[2]: *** Waiting for unfinished jobs....
>> src/ssl.c:11527:61: error: implicit conversion loses integer precision:
>> 'unsigned long' to 'word32' (aka 'unsigned int')
>> [-Werror,-Wshorten-64-to-32]
>>      word32 seedLen = !use_context ? SEED_LEN : SEED_LEN + 2 + 
>> contextLen;
>>             ~~~~~~~ ~~~~~~~~~~~~~^~~~~~~~~~~~
>> src/ssl.c:11591:25: error: implicit conversion loses integer precision:
>> 'size_t' (aka 'unsigned long') to 'word32' (aka 'unsigned int')
>> [-Werror,-Wshorten-64-to-32]
>>      if (wc_PRF_TLS(out, outLen, ssl->arrays->masterSecret, SECRET_LEN,
>>          ~~~~~~~~~~      ^~~~~~
>> src/ssl.c:11592:27: error: implicit conversion loses integer precision:
>> 'size_t' (aka 'unsigned long') to 'word32' (aka 'unsigned int')
>> [-Werror,-Wshorten-64-to-32]
>>              (byte*)label, labelLen, seed, seedLen, 
>> IsAtLeastTLSv1_2(ssl),
>>                            ^~~~~~~~
>> 3 errors generated.
>> make[2]: *** [src/libwolfssl_la-ssl.lo] Error 1
>> make[1]: *** [all-recursive] Error 1
>> make: *** [all] Error 2
>> Time: 0h:00m:27s
>>
>>
Arne Schwabe March 3, 2021, 1:34 a.m. UTC | #21
Am 22.02.21 um 16:28 schrieb Juliusz Sosinowicz:
> Hi Arne,
> 
> have you had any success in compiling OpenVPN with wolfSSL?
> 

Yes, sorry for taking so long. However the client does not work with my
test config (those are on my mac):

2021-03-03 13:19:11 library versions: wolfSSL 4.7.1
2021-03-03 13:19:11 tls_ctx_set_tls_versions: failed to set minimum TLS
version
2021-03-03 13:19:11 Error: private key password verification failed
2021-03-03 13:19:11 Exiting due to fatal error

Note that this profile just has an inline <cert>, <key> and <ca> section.

Another profile, just with <ca> and without certificates fails with:

sudo ./src/openvpn/openvpn ~/dl/focal_generic.ovpn
2021-03-03 13:21:52 DEPRECATED OPTION: --cipher set to 'AES-256-CBC' but
missing in --data-ciphers (AES-256-GCM:AES-128-GCM). Future OpenVPN
version will ignore --cipher for cipher negotiations. Add 'AES-256-CBC'
to --data-ciphers or change --cipher 'AES-256-CBC' to
--data-ciphers-fallback 'AES-256-CBC' to silence this warning.
2021-03-03 13:21:52 OpenVPN 2.6_git
[git:review/wolfsll/5594040c534f20e3+] x86_64-apple-darwin20.3.0 [SSL
(OpenSSL)] [LZ4] [MH/RECVDA] [AEAD] built on Mar  3 2021
2021-03-03 13:21:52 library versions: wolfSSL 4.7.1
Enter Auth Username:arne
Enter Auth Password:
2021-03-03 13:21:58 Cannot load CA certificate file [[INLINE]] (no
entries were read)
2021-03-03 13:21:58 Exiting due to fatal error

To see if the problem is isolated to my macbook, I tried again on Ubuntu
20.10.

% make check
[...]
If the addresses are in use, this test will retry up to two times.
2021-03-03 12:28:25 Cipher negotiation is disabled since neither P2MP
client nor server mode is enabled
2021-03-03 12:28:25 WARNING: file 'sample-keys/server.key' is group or
others accessible
2021-03-03 12:28:25 WARNING: file 'sample-keys/ta.key' is group or
others accessible
2021-03-03 12:28:25 OpenVPN 2.6_git
[git:review/wolfsll/5594040c534f20e3+] x86_64-pc-linux-gnu [SSL
(OpenSSL)] [LZO] [LZ4] [EPOLL] [MH/PKTINFO] [AEAD] built on Mar  3 2021
2021-03-03 12:28:25 library versions: wolfSSL 4.7.1, LZO 2.10
2021-03-03 12:28:25 net_route_v4_best_gw query: dst 0.0.0.0
2021-03-03 12:28:25 net_route_v4_best_gw result: via 192.168.188.1 dev eth0
2021-03-03 12:28:25 NOTE: the current --script-security setting may
allow this configuration to call user-defined scripts
2021-03-03 12:28:25 Cipher negotiation is disabled since neither P2MP
client nor server mode is enabled
2021-03-03 12:28:25 OpenVPN 2.6_git
[git:review/wolfsll/5594040c534f20e3+] x86_64-pc-linux-gnu [SSL
(OpenSSL)] [LZO] [LZ4] [EPOLL] [MH/PKTINFO] [AEAD] built on Mar  3 2021
2021-03-03 12:28:25 library versions: wolfSSL 4.7.1, LZO 2.10
2021-03-03 12:28:25 NOTE: the current --script-security setting may
allow this configuration to call user-defined scripts
2021-03-03 12:28:25 tls_ctx_set_tls_versions: failed to set minimum TLS
version
2021-03-03 12:28:25 Error: private key password verification failed
2021-03-03 12:28:25 Exiting due to fatal error
FAIL: t_cltsrv.sh
Test 0: OK
Test 1: OK
Test 2: OK
Test 3: OK
Test 4: OK
Test 5: OK
Test 6: OK
Test 7: OK
PASS: t_net.sh
====================================================
1 of 3 tests failed
(1 test was not run)
Please report to openvpn-users@lists.sourceforge.net
====================================================

Same result for the configs. I tested a config with an not inlined file
then:

[12:32]arne@bionic-client:~% ./wolfo2build/./src/openvpn/openvpn
focal_generic.ovpn
2021-03-03 12:32:54 DEPRECATED OPTION: --cipher set to 'AES-256-CBC' but
missing in --data-ciphers (AES-256-GCM:AES-128-GCM). Future OpenVPN
version will ignore --cipher for cipher negotiations. Add 'AES-256-CBC'
to --data-ciphers or change --cipher 'AES-256-CBC' to
--data-ciphers-fallback 'AES-256-CBC' to silence this warning.
2021-03-03 12:32:54 OpenVPN 2.6_git
[git:review/wolfsll/5594040c534f20e3+] x86_64-pc-linux-gnu [SSL
(OpenSSL)] [LZO] [LZ4] [EPOLL] [MH/PKTINFO] [AEAD] built on Mar  3 2021
2021-03-03 12:32:54 library versions: wolfSSL 4.7.1, LZO 2.10
Enter Auth Username:j
Enter Auth Password:
2021-03-03 12:32:56 Cannot load CA certificate file focal-ca.pem (no
entries were read)
2021-03-03 12:32:56 Exiting due to fatal error
[12:32]{1}arne@bionic-client:~% openssl x509 -in focal-ca.pem
-----BEGIN CERTIFICATE-----
MIHzMIGmoAMCAQICAgDrMAUGAytlcDASMRAwDgYDVQQDDAdlZDI1IENBMB4XDTIx
MDEwNzE3MjQxNloXDTMxMDEwNjE3MjQxNlowEjEQMA4GA1UEAwwHZWQyNSBDQTAq
MAUGAytlcAMhAFP90d3bP9Bk49MFBtQEXqtdvGlymOped9L+X17paUfAoyAwHjAP
BgNVHRMBAf8EBTADAQH/MAsGA1UdDwQEAwIBBjAFBgMrZXADQQDbdEko8+2dsfgb
NSejIFv3JRw7FymlIH6dBnH9kN4qCkcm1/avhErxURGUJgounEn4UZtK5w1u+Wf8
y6/RvusO
-----END CERTIFICATE-----


And that also fails.

So it compiles now but in the past it got to a point that it connected
and worked.

Arne
Juliusz Sosinowicz March 12, 2021, 4:12 a.m. UTC | #22
Hi Arne,

I found that the connecting issue is that 
wolfSSL_CTX_set_min_proto_version will fail when the user (in this case 
OpenVPN) tries to set a protocol version that was not compiled in. I 
modified our configure.ac script when building for OpenVPN along with 
some additional fixes in this pull request: 
https://github.com/wolfSSL/wolfssl/pull/3871

I also found an error in one of OpenVPN's unit tests. I submitted a 
patch for that test in a separate email.

Sincerely
Juliusz

On 03/03/2021 13:34, Arne Schwabe wrote:
> Am 22.02.21 um 16:28 schrieb Juliusz Sosinowicz:
>> Hi Arne,
>>
>> have you had any success in compiling OpenVPN with wolfSSL?
>>
> Yes, sorry for taking so long. However the client does not work with my
> test config (those are on my mac):
>
> 2021-03-03 13:19:11 library versions: wolfSSL 4.7.1
> 2021-03-03 13:19:11 tls_ctx_set_tls_versions: failed to set minimum TLS
> version
> 2021-03-03 13:19:11 Error: private key password verification failed
> 2021-03-03 13:19:11 Exiting due to fatal error
>
> Note that this profile just has an inline <cert>, <key> and <ca> section.
>
> Another profile, just with <ca> and without certificates fails with:
>
> sudo ./src/openvpn/openvpn ~/dl/focal_generic.ovpn
> 2021-03-03 13:21:52 DEPRECATED OPTION: --cipher set to 'AES-256-CBC' but
> missing in --data-ciphers (AES-256-GCM:AES-128-GCM). Future OpenVPN
> version will ignore --cipher for cipher negotiations. Add 'AES-256-CBC'
> to --data-ciphers or change --cipher 'AES-256-CBC' to
> --data-ciphers-fallback 'AES-256-CBC' to silence this warning.
> 2021-03-03 13:21:52 OpenVPN 2.6_git
> [git:review/wolfsll/5594040c534f20e3+] x86_64-apple-darwin20.3.0 [SSL
> (OpenSSL)] [LZ4] [MH/RECVDA] [AEAD] built on Mar  3 2021
> 2021-03-03 13:21:52 library versions: wolfSSL 4.7.1
> Enter Auth Username:arne
> Enter Auth Password:
> 2021-03-03 13:21:58 Cannot load CA certificate file [[INLINE]] (no
> entries were read)
> 2021-03-03 13:21:58 Exiting due to fatal error
>
> To see if the problem is isolated to my macbook, I tried again on Ubuntu
> 20.10.
>
> % make check
> [...]
> If the addresses are in use, this test will retry up to two times.
> 2021-03-03 12:28:25 Cipher negotiation is disabled since neither P2MP
> client nor server mode is enabled
> 2021-03-03 12:28:25 WARNING: file 'sample-keys/server.key' is group or
> others accessible
> 2021-03-03 12:28:25 WARNING: file 'sample-keys/ta.key' is group or
> others accessible
> 2021-03-03 12:28:25 OpenVPN 2.6_git
> [git:review/wolfsll/5594040c534f20e3+] x86_64-pc-linux-gnu [SSL
> (OpenSSL)] [LZO] [LZ4] [EPOLL] [MH/PKTINFO] [AEAD] built on Mar  3 2021
> 2021-03-03 12:28:25 library versions: wolfSSL 4.7.1, LZO 2.10
> 2021-03-03 12:28:25 net_route_v4_best_gw query: dst 0.0.0.0
> 2021-03-03 12:28:25 net_route_v4_best_gw result: via 192.168.188.1 dev eth0
> 2021-03-03 12:28:25 NOTE: the current --script-security setting may
> allow this configuration to call user-defined scripts
> 2021-03-03 12:28:25 Cipher negotiation is disabled since neither P2MP
> client nor server mode is enabled
> 2021-03-03 12:28:25 OpenVPN 2.6_git
> [git:review/wolfsll/5594040c534f20e3+] x86_64-pc-linux-gnu [SSL
> (OpenSSL)] [LZO] [LZ4] [EPOLL] [MH/PKTINFO] [AEAD] built on Mar  3 2021
> 2021-03-03 12:28:25 library versions: wolfSSL 4.7.1, LZO 2.10
> 2021-03-03 12:28:25 NOTE: the current --script-security setting may
> allow this configuration to call user-defined scripts
> 2021-03-03 12:28:25 tls_ctx_set_tls_versions: failed to set minimum TLS
> version
> 2021-03-03 12:28:25 Error: private key password verification failed
> 2021-03-03 12:28:25 Exiting due to fatal error
> FAIL: t_cltsrv.sh
> Test 0: OK
> Test 1: OK
> Test 2: OK
> Test 3: OK
> Test 4: OK
> Test 5: OK
> Test 6: OK
> Test 7: OK
> PASS: t_net.sh
> ====================================================
> 1 of 3 tests failed
> (1 test was not run)
> Please report to openvpn-users@lists.sourceforge.net
> ====================================================
>
> Same result for the configs. I tested a config with an not inlined file
> then:
>
> [12:32]arne@bionic-client:~% ./wolfo2build/./src/openvpn/openvpn
> focal_generic.ovpn
> 2021-03-03 12:32:54 DEPRECATED OPTION: --cipher set to 'AES-256-CBC' but
> missing in --data-ciphers (AES-256-GCM:AES-128-GCM). Future OpenVPN
> version will ignore --cipher for cipher negotiations. Add 'AES-256-CBC'
> to --data-ciphers or change --cipher 'AES-256-CBC' to
> --data-ciphers-fallback 'AES-256-CBC' to silence this warning.
> 2021-03-03 12:32:54 OpenVPN 2.6_git
> [git:review/wolfsll/5594040c534f20e3+] x86_64-pc-linux-gnu [SSL
> (OpenSSL)] [LZO] [LZ4] [EPOLL] [MH/PKTINFO] [AEAD] built on Mar  3 2021
> 2021-03-03 12:32:54 library versions: wolfSSL 4.7.1, LZO 2.10
> Enter Auth Username:j
> Enter Auth Password:
> 2021-03-03 12:32:56 Cannot load CA certificate file focal-ca.pem (no
> entries were read)
> 2021-03-03 12:32:56 Exiting due to fatal error
> [12:32]{1}arne@bionic-client:~% openssl x509 -in focal-ca.pem
> -----BEGIN CERTIFICATE-----
> MIHzMIGmoAMCAQICAgDrMAUGAytlcDASMRAwDgYDVQQDDAdlZDI1IENBMB4XDTIx
> MDEwNzE3MjQxNloXDTMxMDEwNjE3MjQxNlowEjEQMA4GA1UEAwwHZWQyNSBDQTAq
> MAUGAytlcAMhAFP90d3bP9Bk49MFBtQEXqtdvGlymOped9L+X17paUfAoyAwHjAP
> BgNVHRMBAf8EBTADAQH/MAsGA1UdDwQEAwIBBjAFBgMrZXADQQDbdEko8+2dsfgb
> NSejIFv3JRw7FymlIH6dBnH9kN4qCkcm1/avhErxURGUJgounEn4UZtK5w1u+Wf8
> y6/RvusO
> -----END CERTIFICATE-----
>
>
> And that also fails.
>
> So it compiles now but in the past it got to a point that it connected
> and worked.
>
> Arne
Arne Schwabe March 17, 2021, 6:13 a.m. UTC | #23
Am 12.03.21 um 16:12 schrieb Juliusz Sosinowicz:
> Hi Arne,
> 
> I found that the connecting issue is that
> wolfSSL_CTX_set_min_proto_version will fail when the user (in this case
> OpenVPN) tries to set a protocol version that was not compiled in. I
> modified our configure.ac script when building for OpenVPN along with
> some additional fixes in this pull request:
> https://github.com/wolfSSL/wolfssl/pull/3871
> 
> I also found an error in one of OpenVPN's unit tests. I submitted a
> patch for that test in a separate email.

Using an Ed25519 certificate results in

2021-03-17 14:57:23 us=212254 OpenSSL: unknown error number
2021-03-17 14:57:23 us=212262 Cannot load certificate file
/Users/arne/tmp/alice.pem
2021-03-17 14:57:23 us=212265 Exiting due to fatal error


The configure.ac of WolfSSL should be updated to signal EKM support:


AC_CHECK_HEADER([wolfssl/options.h],,[AC_MSG_ERROR([wolfSSL header
wolfssl/options.h not found!])])
        fi

+     # Wolfssl emulate OpenSSL and has EKM
+       have_export_keying_material="yes"
+
        AC_DEFINE([HAVE_HMAC_CTX_NEW], [1], [Emulate AC_CHECK_FUNCS
since these are defined as macros])
        AC_DEFINE([HAVE_HMAC_CTX_FREE], [1], [Emulate AC_CHECK_FUNCS
since these are defined as macros])
        AC_DEFINE([HAVE_HMAC_CTX_RESET], [1], [Emulate AC_CHECK_FUNCS
since these are defined as macros])

Other than it seem to work in the tests that I threw at it.

I would consider this an ACK. @Gert do you want a new version with the
configure.ac fixed?

Arne
Gert Doering March 17, 2021, 6:22 a.m. UTC | #24
Hi,

On Wed, Mar 17, 2021 at 06:13:04PM +0100, Arne Schwabe wrote:
> I would consider this an ACK. @Gert do you want a new version with the
> configure.ac fixed?

Since this is a real code change, I'd prefer to have an updated patch
with that change included.

gert
Juliusz Sosinowicz March 17, 2021, 6:58 a.m. UTC | #25
Hi Arne,

wolfSSL does not support Ed25519 certificates in the compatibility layer.

I added the EKM signaling locally. I can submit the patch with this 
modification if you would like me to.

Sincerely
Juliusz

On 17/03/2021 18:13, Arne Schwabe wrote:
> Am 12.03.21 um 16:12 schrieb Juliusz Sosinowicz:
>> Hi Arne,
>>
>> I found that the connecting issue is that
>> wolfSSL_CTX_set_min_proto_version will fail when the user (in this case
>> OpenVPN) tries to set a protocol version that was not compiled in. I
>> modified our configure.ac script when building for OpenVPN along with
>> some additional fixes in this pull request:
>> https://github.com/wolfSSL/wolfssl/pull/3871
>>
>> I also found an error in one of OpenVPN's unit tests. I submitted a
>> patch for that test in a separate email.
> Using an Ed25519 certificate results in
>
> 2021-03-17 14:57:23 us=212254 OpenSSL: unknown error number
> 2021-03-17 14:57:23 us=212262 Cannot load certificate file
> /Users/arne/tmp/alice.pem
> 2021-03-17 14:57:23 us=212265 Exiting due to fatal error
>
>
> The configure.ac of WolfSSL should be updated to signal EKM support:
>
>
> AC_CHECK_HEADER([wolfssl/options.h],,[AC_MSG_ERROR([wolfSSL header
> wolfssl/options.h not found!])])
>          fi
>
> +     # Wolfssl emulate OpenSSL and has EKM
> +       have_export_keying_material="yes"
> +
>          AC_DEFINE([HAVE_HMAC_CTX_NEW], [1], [Emulate AC_CHECK_FUNCS
> since these are defined as macros])
>          AC_DEFINE([HAVE_HMAC_CTX_FREE], [1], [Emulate AC_CHECK_FUNCS
> since these are defined as macros])
>          AC_DEFINE([HAVE_HMAC_CTX_RESET], [1], [Emulate AC_CHECK_FUNCS
> since these are defined as macros])
>
> Other than it seem to work in the tests that I threw at it.
>
> I would consider this an ACK. @Gert do you want a new version with the
> configure.ac fixed?
>
> Arne
>
Juliusz Sosinowicz March 17, 2021, 6:59 a.m. UTC | #26
My apologies. I didn't notice your reply Gert. I will submit an updated 
patch.

Sincerely
Juliusz

On 17/03/2021 18:22, Gert Doering wrote:
> Hi,
>
> On Wed, Mar 17, 2021 at 06:13:04PM +0100, Arne Schwabe wrote:
>> I would consider this an ACK. @Gert do you want a new version with the
>> configure.ac fixed?
> Since this is a real code change, I'd prefer to have an updated patch
> with that change included.
>
> gert
>

Patch

diff --git a/configure.ac b/configure.ac
index 273a8d1b..56d63555 100644
--- a/configure.ac
+++ b/configure.ac
@@ -269,16 +269,23 @@  AC_ARG_WITH(
 
 AC_ARG_WITH(
 	[crypto-library],
-	[AS_HELP_STRING([--with-crypto-library=library], [build with the given crypto library, TYPE=openssl|mbedtls @<:@default=openssl@:>@])],
+	[AS_HELP_STRING([--with-crypto-library=library], [build with the given crypto library, TYPE=openssl|mbedtls|wolfssl @<:@default=openssl@:>@])],
 	[
 		case "${withval}" in
-			openssl|mbedtls) ;;
+			openssl|mbedtls|wolfssl) ;;
 			*) AC_MSG_ERROR([bad value ${withval} for --with-crypto-library]) ;;
 		esac
 	],
 	[with_crypto_library="openssl"]
 )
 
+AC_ARG_ENABLE(
+	[wolfssl-options-h],
+	[AS_HELP_STRING([--disable-wolfssl-options-h], [Disable including options.h in wolfSSL @<:@default=yes@:>@])],
+	,
+	[enable_wolfssl_options_h="yes"]
+)
+
 AC_ARG_VAR([PLUGINDIR], [Path of plug-in directory @<:@default=LIBDIR/openvpn/plugins@:>@])
 if test -n "${PLUGINDIR}"; then
 	plugindir="${PLUGINDIR}"
@@ -1022,6 +1029,89 @@  elif test "${with_crypto_library}" = "mbedtls"; then
 	AC_DEFINE([ENABLE_CRYPTO_MBEDTLS], [1], [Use mbed TLS library])
 	CRYPTO_CFLAGS="${MBEDTLS_CFLAGS}"
 	CRYPTO_LIBS="${MBEDTLS_LIBS}"
+
+elif test "${with_crypto_library}" = "wolfssl"; then
+	AC_ARG_VAR([WOLFSSL_CFLAGS], [C compiler flags for wolfssl])
+	AC_ARG_VAR([WOLFSSL_LIBS], [linker flags for wolfssl])
+	AC_ARG_VAR([WOLFSSL_DIR], [Path to the wolfssl directory @<:@default=/usr/local/include/wolfssl@:>@])
+	if test -n "${WOLFSSL_DIR}"; then
+		wolfssldir="${WOLFSSL_DIR}"
+	else
+		wolfssldir="/usr/local/include/wolfssl"
+	fi
+
+	saved_CFLAGS="${CFLAGS}"
+	saved_LIBS="${LIBS}"
+
+	if test -z "${WOLFSSL_CFLAGS}" -a -z "${WOLFSSL_LIBS}"; then
+		# if the user did not explicitly specify flags, try to autodetect
+		LIBS="${LIBS} -lwolfssl -lm -pthread"
+		AC_CHECK_LIB(
+			[wolfssl],
+			[wolfSSL_Init],
+			[],
+			[AC_MSG_ERROR([Could not link wolfSSL library.])]
+		)
+		AC_CHECK_HEADER([wolfssl/options.h],,[AC_MSG_ERROR([wolfSSL header wolfssl/options.h not found!])])
+	fi
+
+	AC_DEFINE([HAVE_HMAC_CTX_NEW], [1], [Emulate AC_CHECK_FUNCS since these are defined as macros])
+	AC_DEFINE([HAVE_HMAC_CTX_FREE], [1], [Emulate AC_CHECK_FUNCS since these are defined as macros])
+	AC_DEFINE([HAVE_HMAC_CTX_RESET], [1], [Emulate AC_CHECK_FUNCS since these are defined as macros])
+	AC_DEFINE([HAVE_EVP_MD_CTX_NEW], [1], [Emulate AC_CHECK_FUNCS since these are defined as macros])
+	AC_DEFINE([HAVE_EVP_MD_CTX_FREE], [1], [Emulate AC_CHECK_FUNCS since these are defined as macros])
+	AC_DEFINE([HAVE_EVP_MD_CTX_RESET], [1], [Emulate AC_CHECK_FUNCS since these are defined as macros])
+	AC_DEFINE([HAVE_EVP_CIPHER_CTX_RESET], [1], [Emulate AC_CHECK_FUNCS since these are defined as macros])
+	AC_DEFINE([HAVE_OPENSSL_VERSION], [1], [Emulate AC_CHECK_FUNCS since these are defined as macros])
+	AC_DEFINE([HAVE_SSL_CTX_GET_DEFAULT_PASSWD_CB], [1], [Emulate AC_CHECK_FUNCS since these are defined as macros])
+	AC_DEFINE([HAVE_SSL_CTX_GET_DEFAULT_PASSWD_CB_USERDATA], [1], [Emulate AC_CHECK_FUNCS since these are defined as macros])
+	AC_DEFINE([HAVE_SSL_CTX_SET_SECURITY_LEVEL], [1], [Emulate AC_CHECK_FUNCS since these are defined as macros])
+	AC_DEFINE([HAVE_X509_GET0_NOTBEFORE], [1], [Emulate AC_CHECK_FUNCS since these are defined as macros])
+	AC_DEFINE([HAVE_X509_GET0_NOTAFTER], [1], [Emulate AC_CHECK_FUNCS since these are defined as macros])
+	AC_DEFINE([HAVE_X509_GET0_PUBKEY], [1], [Emulate AC_CHECK_FUNCS since these are defined as macros])
+	AC_DEFINE([HAVE_X509_STORE_GET0_OBJECTS], [1], [Emulate AC_CHECK_FUNCS since these are defined as macros])
+	AC_DEFINE([HAVE_X509_OBJECT_FREE], [1], [Emulate AC_CHECK_FUNCS since these are defined as macros])
+	AC_DEFINE([HAVE_X509_OBJECT_GET_TYPE], [1], [Emulate AC_CHECK_FUNCS since these are defined as macros])
+	AC_DEFINE([HAVE_EVP_PKEY_ID], [1], [Emulate AC_CHECK_FUNCS since these are defined as macros])
+	AC_DEFINE([HAVE_EVP_PKEY_GET0_RSA], [1], [Emulate AC_CHECK_FUNCS since these are defined as macros])
+	AC_DEFINE([HAVE_EVP_PKEY_GET0_DSA], [1], [Emulate AC_CHECK_FUNCS since these are defined as macros])
+	AC_DEFINE([HAVE_EVP_PKEY_GET0_EC_KEY], [1], [Emulate AC_CHECK_FUNCS since these are defined as macros])
+	AC_DEFINE([HAVE_RSA_SET_FLAGS], [1], [Emulate AC_CHECK_FUNCS since these are defined as macros])
+	AC_DEFINE([HAVE_RSA_BITS], [1], [Emulate AC_CHECK_FUNCS since these are defined as macros])
+	AC_DEFINE([HAVE_RSA_GET0_KEY], [1], [Emulate AC_CHECK_FUNCS since these are defined as macros])
+	AC_DEFINE([HAVE_RSA_SET0_KEY], [1], [Emulate AC_CHECK_FUNCS since these are defined as macros])
+	AC_DEFINE([HAVE_DSA_GET0_PQG], [1], [Emulate AC_CHECK_FUNCS since these are defined as macros])
+	AC_DEFINE([HAVE_DSA_BITS], [1], [Emulate AC_CHECK_FUNCS since these are defined as macros])
+	AC_DEFINE([HAVE_RSA_METH_NEW], [1], [Emulate AC_CHECK_FUNCS since these are defined as macros])
+	AC_DEFINE([HAVE_RSA_METH_FREE], [1], [Emulate AC_CHECK_FUNCS since these are defined as macros])
+	AC_DEFINE([HAVE_RSA_METH_SET_PUB_ENC], [1], [Emulate AC_CHECK_FUNCS since these are defined as macros])
+	AC_DEFINE([HAVE_RSA_METH_SET_PUB_DEC], [1], [Emulate AC_CHECK_FUNCS since these are defined as macros])
+	AC_DEFINE([HAVE_RSA_METH_SET_PRIV_ENC], [1], [Emulate AC_CHECK_FUNCS since these are defined as macros])
+	AC_DEFINE([HAVE_RSA_METH_SET_PRIV_DEC], [1], [Emulate AC_CHECK_FUNCS since these are defined as macros])
+	AC_DEFINE([HAVE_RSA_METH_SET_INIT], [1], [Emulate AC_CHECK_FUNCS since these are defined as macros])
+	AC_DEFINE([HAVE_RSA_METH_SET_SIGN], [1], [Emulate AC_CHECK_FUNCS since these are defined as macros])
+	AC_DEFINE([HAVE_RSA_METH_SET_FINISH], [1], [Emulate AC_CHECK_FUNCS since these are defined as macros])
+	AC_DEFINE([HAVE_RSA_METH_SET0_APP_DATA], [1], [Emulate AC_CHECK_FUNCS since these are defined as macros])
+	AC_DEFINE([HAVE_RSA_METH_GET0_APP_DATA], [1], [Emulate AC_CHECK_FUNCS since these are defined as macros])
+	AC_DEFINE([HAVE_EC_GROUP_ORDER_BITS], [1], [Emulate AC_CHECK_FUNCS since these are defined as macros])
+	
+	have_crypto_aead_modes="yes"
+	have_crypto="yes"
+    
+	if test "${enable_wolfssl_options_h}" = "yes"; then
+		AC_DEFINE([EXTERNAL_OPTS_OPENVPN], [1], [Include options.h from wolfSSL library])
+	else
+		AC_DEFINE([WOLFSSL_USER_SETTINGS], [1], [Use custom user_settings.h file for wolfSSL library])
+	fi
+	
+	WOLFSSL_CFLAGS="${WOLFSSL_CFLAGS} -I${wolfssldir}"
+	CFLAGS="${WOLFSSL_CFLAGS} ${CFLAGS}"
+	LIBS="${WOLFSSL_LIBS} ${LIBS}"
+	
+	AC_DEFINE([ENABLE_CRYPTO_WOLFSSL], [1], [Use wolfSSL crypto library])
+	AC_DEFINE([ENABLE_CRYPTO_OPENSSL], [1], [Use wolfSSL openssl compatibility layer])
+	CRYPTO_CFLAGS="${WOLFSSL_CFLAGS}"
+	CRYPTO_LIBS="${WOLFSSL_LIBS}"
 else
 	AC_MSG_ERROR([Invalid crypto library: ${with_crypto_library}])
 fi
diff --git a/src/openvpn/syshead.h b/src/openvpn/syshead.h
index cafe4719..78e434ab 100644
--- a/src/openvpn/syshead.h
+++ b/src/openvpn/syshead.h
@@ -587,7 +587,8 @@  socket_defined(const socket_descriptor_t sd)
 /*
  * Do we have CryptoAPI capability?
  */
-#if defined(_WIN32) && defined(ENABLE_CRYPTO_OPENSSL)
+#if defined(_WIN32) && defined(ENABLE_CRYPTO_OPENSSL) && \
+        !defined(ENABLE_CRYPTO_WOLFSSL)
 #define ENABLE_CRYPTOAPI
 #endif