| Message ID | 20200616180046.8069-1-juliusz@wolfssl.com |
|---|---|
| State | Changes Requested |
| Headers | show |
| Series | [Openvpn-devel] Support for wolfSSL in OpenVPN | expand |
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 >
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
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 > >
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
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 > >
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
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.
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 >
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
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.
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
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
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(&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
</pre>
</blockquote>
</body>
</html>
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
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
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
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
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 > >
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 > >
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 >> >>
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
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
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
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
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 >
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 >
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
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(-)