Looks like we have a regression after libressl 2.4 update I see following errors in console Aug 25 17:14:59 sphinx charon: 00[LIB] plugin 'openssl' failed to load: /usr/local/lib/ipsec/plugins/libstrongswan-openssl.so: Undefined symbol "CMS_RecipientInfo_ktri_get0_signer_id" Aug 25 17:14:59 sphinx charon: 05[IKE] configured DH group MODP_3072 not supported IKE_SA can't be established with these. The workaround is to rollback to 2.3.7 or link against base.
Also don't build: openssl_plugin.c:580:7: error: use of undeclared identifier 'OPENSSL_INIT_ENGINE_ALL_BUILTIN' OPENSSL_INIT_ENGINE_ALL_BUILTIN, NULL); ^ needs this patch: https://github.com/HardenedBSD/hardenedbsd-ports/blob/c2091a265c9c78401cd1f4135de97590c8e7c454/security/strongswan/files/patch-src_libstrongswan_plugins_openssl_openssl__plugin.c does not know, if it solves above issue.
(In reply to w.schwarzenfeld from comment #1) I applied this patch before build, so I don't know if it helps to build, however I suppose yes, if it doesn't build for you.
(In reply to Ivan from comment #0) I would assume that there's improper linking (base vs ports). Please provide build logs.
Created attachment 175126 [details] build log /usr/local/lib/ipsec/plugins/libstrongswan-openssl.so: libcrypto.so.38 => /usr/local/lib/libcrypto.so.38 (0x801212000) libc.so.7 => /lib/libc.so.7 (0x800823000) /usr/local/lib/libcrypto.so.38 was installed by package libressl-2.4.2 in make.conf DEFAULT_VERSIONS+=ssl=libressl
I ran into the same error today. Even *with* the latest strongswan patch for LIBRESSL_VERSION_NUMBER, I cannot get it to work without resurrecting: https://github.com/opnsense/ports/commit/7e8ea59ca
(In reply to Franco Fichtner from comment #5) I'd hoped that 5.5.1 may have fixed the problem but (on virgin systems with no configuration settings) ... On FreeBSD10.3Stable amd64 with libressl using gcc5 # /usr/local/libexec/ipsec/charon 00[DMN] Starting IKE charon daemon (strongSwan 5.5.1, FreeBSD 10.3-STABLE, amd64) 00[LIB] plugin 'openssl' failed to load: /usr/local/lib/ipsec/plugins/libstrongswan-openssl.so: Undefined symbol "RSA_set0_factors" # ldd /usr/local/lib/ipsec/plugins/libstrongswan-openssl.so /usr/local/lib/ipsec/plugins/libstrongswan-openssl.so: libcrypto.so.38 => /usr/local/lib/libcrypto.so.38 (0x801613000) libc.so.7 => /lib/libc.so.7 (0x800822000) # grep LIBRESSL_VERSION_NUMBER /usr/ports/security/strongswan/*/* /usr/ports/security/strongswan/files/patch-src_libstrongswan_plugins_openssl_openssl__plugin.c:+#if OPENSSL_VERSION_NUMBER >= 0x10100000L && !defined(LIBRESSL_VERSION_NUMBER) On i386 and security/openssl and gcc5 otherwise same make.conf, we get # /usr/local/libexec/ipsec/charon 00[DMN] Starting IKE charon daemon (strongSwan 5.5.1, FreeBSD 10.3-STABLE, i386) 00[KNL] unable to create PF_KEY socket 00[NET] could not open socket: Protocol not supported ... Looks like libstrongswan-openssl is looking for openssl internal symbols?
StrongSwan has a considerable amount of ifdefs around different versions of OPENSSL_VERSION_NUMBER instead of testing for specific features. It seems that the LibreSSL hardcoded variant just doesn't cut it there. We may have to face the fact that we're the early adopters here and need to put the bug upstream? We have all the data points needed to fix this now I think, but it should be them to write a patch based on the correct LIBRESSL_VERSION_NUMBER.
Issue reported upstream: https://wiki.strongswan.org/issues/2165
(In reply to Franco Fichtner from comment #8) Thanks Franco, I read the upstream track. Unfortunately 5.5.2 continues with the same issue on FreeBSD 11.0 stable with libressl, so it appears that we have to patch ourselves. Is https://github.com/opnsense/ports/commit/7e8ea59cabc still the best way to address? Namely (in my libressl 2.4.5) change the line in: /var/ports/usr/ports/security/libressl/work/libressl-2.4.5/include/openssl/opensslv.h from #define OPENSSL_VERSION_NUMBER 0x20000000L to #define OPENSSL_VERSION_NUMBER 0x1000107fL ?
(In reply to dewayne from comment #9) Looks like it. Still the best option. I tried to ask LibreSSL if we could have an optional workaround for targeted builds as pinning the OpenSSL version in general is tricky. For 2.4.x it works well, but 2.5.x was just released so I don't know where that will lead. http://marc.info/?l=libressl&m=147816235401460&w=2 No more responses or incentives there as well. Eventually, strongSwan needs to be made aware of how feature macros or libressl version numbers are used to achieve the same. I think that's something we need to do and push upstream ourselves. Cheers, Franco
Created attachment 181958 [details] svn diff for security/strongswan There's 60 OpenSSL version number checks in the code. This patch just resets compat to the time of forking (1.0.1f) Please test and let me know if this at least works...
(In reply to Bernard Spil from comment #11) Thanks Bernand. There was a differences between your patch and what was on latests ports for strongswan 5.5.2. Regardless, this is heading in the right direction. I moved your patch higher in the file, prior to first comparison with the openssl version. Result: # /usr/local/libexec/ipsec/charon 00[DMN] Starting IKE charon daemon (strongSwan 5.5.2, FreeBSD 11.0-STABLE, amd64) 00[LIB] plugin 'openssl' failed to load: /usr/local/lib/ipsec/plugins/libstrongswan-openssl.so: Undefined symbol "RSA_set0_factors" which is used in /var/ports/usr/ports/security/strongswan/work/strongswan-5.5.2/src/libstrongswan/plugins/openssl/openssl_rsa_private_key.c Unfortunate. The patch used was: --- src/libstrongswan/plugins/openssl/openssl_plugin.c.orig 2017-04-21 14:46:36.000000000 +1000 +++ src/libstrongswan/plugins/openssl/openssl_plugin.c 2017-04-21 14:47:25.000000000 +1000 @@ -65,6 +65,10 @@ openssl_plugin_t public; }; +#ifdef LIBRESSL_VERSION_NUMBER +#define OPENSSL_VERSION_NUMBER 0x1000107fL +#endif + /** * OpenSSL is thread-safe since 1.1.0 */
Created attachment 181970 [details] svn diff for security/strongswan A comment that I thought I'd submitted was missing. The RSA_set0_key and other methods only exist in versions > 1.1 https://wiki.openssl.org/index.php/OpenSSL_1.1.0_Changes Attached patch adds the missing methods. That should fix the Undefined symbol "RSA_set0_factors" issue. You moved the #ifdef LIBRESSL_VERSION_NUMBER to later in the openssl_plugin.c file which surprised me. Quick hack of the compat stuff, should land in a separate openssl_compat.c file I'd think but good enough to upstream if it works.
Created attachment 182037 [details] Patch for RSA_set0_key and DH_set0_key
(In reply to Bernard Spil from comment #13) Bernard, Thanks for your patches and the reference to https://wiki.openssl.org/index.php/OpenSSL_1.1.0_Changes Clean compiles were achieved. Running /usr/local/libexec/ipsec/charon returned undefined DH_set0_key. Which I added to the patch. Unfortunately we now receive [b2.hs] Installing strongswan-5.5.2... 00[DMN] Starting IKE charon daemon (strongSwan 5.5.2, FreeBSD 11.0-STABLE, amd64) 00[LIB] plugin 'openssl' failed to load: /usr/local/lib/ipsec/plugins/libstrongswan-openssl.so: Undefined symbol "OBJ_get0_data" Unfortunately I then added OBJ_get0_data to the patch, which was unnecessary as it is defined in ./src/libstrongswan/plugins/openssl/openssl_util.c So this is as far as I was able to get.
(In reply to dewayne from comment #15) src/libstrongswan/plugins/openssl/openssl_util.c Line 26 #if OPENSSL_VERSION_NUMBER < 0x10100000L || defined(LIBRESSL_VERSION_NUMBER) Fortunately direct OBJ access has not been made opaque yet, seems to work. See openssl/asn1.h
Created attachment 182070 [details] libressl Makefile patch - helps migration to libressl Bernard, Thanks for your help. After a few more iterations, of chasing my tail with patches, I decided that this game had to end. I hacked /usr/include/openssl/opensslv.h #define OPENSSL_VERSION_NUMBER 0x1000107fL /* openssl at time of libressl fork */ /* #define OPENSSL_VERSION_NUMBER 0x20000000L Just to test if strongswan will ever work!*/ and for good measure "ln -s /usr/local/include/openssl /usr/include/openssl". I moved my working copies of strongswan and hostapd; svnlite pulled the latest and rebuilt. I've added my patch to the libressl Makefile, which I've included (discard my CFLAGS change as that is local. I only use/tested on amd64, hence the constraint. Result strongswan 5.5.2, and other problematic ports: freeradius3, haproxy and hostapd 2.6 all built cleanly and preliminary testing looks positive. Perhaps not a long-term solution, and I'm sure we need to get this fixed for the long haul. My realistic expectation - ALL upstream applications that use openssl 1.0.X internals in their source, are going to need to change/'hack around' to accomodate the new openssl 1.1.x (opaque) structures. At which point we'll need to address properly, but until openssl 1.0.x retires &/or libressl changes significantly we "should" be ok until then. For me, the key trigger for change will be, who actually provides safe ECC, but that's another story. ;)
(In reply to dewayne from comment #17) I meant I "hacked" /usr/local/include/openssl/opensslv.h and not /usr/include/openssl/opensslv.h. I had deleted the later's subdirectory and used a soft link as a precautionary step. Doesn't matter how carefully you read something that's going to be public, you'll always manage to embarrass yourself. :/
Created attachment 182090 [details] svn diff for security/strongswan strongSwan makes a bit of a mess of the OpenSSL includes. Files checking OPENSSL_VERSION_NUMBER openssl_crl.c openssl_diffie_hellman.c openssl_ec_private_key.c openssl_ec_public_key.c openssl_gcm.c openssl_hmac.c openssl_pkcs7.c openssl_plugin.c openssl_plugin.c.orig openssl_rsa_private_key.c openssl_rsa_public_key.c openssl_sha1_prf.c openssl_util.c openssl_x509.c cp -p Apart from _gcm and _pkcs7 these don't include opensslv.h. Most get OPENSSL_VERSION_NUMBER defined through include openssl_util.h -> <openssl/bn.h> -> <openssl/crypto.h> -> <openssl/opensslv.h> Files NOT including openssl_util.h get OPENSSL_VERSION_NUMBER defined through openssl_gcm.c -> opensslv.h openssl_hmac.c NONE openssl_sha1_prf.c NONE It is entirely possible that the path is different in OpenSSL. I've created new files openssl_compat.h openssl_compat.c Modified all files checking OPENSSL_VERSION and not including openssl_util.h to add include openssl_compat.h Modified openssl_util.h to include openssl_compat.h Added openssl_compat.h and openssl_compat.c to Makefile.am (and ran automake) Please find a patch to test attached. I've created an account on strongswan.org but that's pending moderator approval. Dewayne, Franco, can you test this patch?
Created attachment 182091 [details] svn diff for security/strongswan Sorry... That was output of svn status not svn diff.
(In reply to Bernard Spil from comment #20) Good approach. The patch applied cleanly, and trivial testing was successful on a system with libressl. Thank-you. However the patches caused a failure when building with openssl. There were quite a few errors generated. In file included from openssl_compat.c:18: ./openssl_compat.h:30:10: fatal error: 'openssl/opensslfeatures.h' file not found #include <openssl/opensslfeatures.h> ^~~~~~~~~~~~~~~~~~~~~~~~~~~ opensslfeatures.h only exists in libressl-2.5.3.tar.gz. It is not in either: /distfiles/openssl-1.0.2k/openssl-1.0.2k.tar.gz /distfiles/openssl-1.1.0e.tar.gz Aside: both opensslv.h and opensslconf.h exist in all ;)
(In reply to dewayne from comment #21) Moving opensslfeatures.h into the libressl test block is sufficient for both openssl and libress :) +#include <openssl/opensslv.h> +#include <openssl/opensslconf.h> + +#ifdef LIBRESSL_VERSION_NUMBER +#include <openssl/opensslfeatures.h> +#undef OPENSSL_VERSION_NUMBER +#define OPENSSL_VERSION_NUMBER 0x1000107fL +#endif /* LIBRESSL_VERSION_NUMBER */
Just want to check now, does the latest patch now work successfully with libressl and openssl. I haven't had time to fully test using libressl.
(In reply to strongswan from comment #23) Waiting for Franco and Dewayne to report back on the patch.
It's difficult to test for me as we still jam OPENSSL_VERSION_NUMBER into libressl headers itself and are on 2.4 for a while longer.
Test of LibreSSL 2.5.5 on strongSwan 5.5.3 built from yesterday's ports: still doesn't work.
I'm using this now as it allows to set LibreSSL compat on a per-port basis. https://github.com/opnsense/ports/commit/d76955f3d Cheers, Franco
(In reply to Franco Fichtner from comment #28) Thanks Franco. Strongswan 5.6.0 builds on my FreeBSD 11.1 Stable i386/amd64. Unfortunately on libressl, # /usr/local/libexec/ipsec/charon coughs up 00[LIB] plugin 'openssl' failed to load: /usr/local/lib/ipsec/plugins/libstrongswan-openssl.so: Undefined symbol "X509_get0_signature" with libressl 2.5.5. Sequence -1. svnlite update --accept=tc /usr/ports 0. Rebuild all ports, strongswan failed (due to previous files/patch*) 1. remove /usr/ports/security/strongswan 2. svnlite update /usr/ports/security/strongswan 3. make -C /usr/ports/security/strongswan clean package 4. Installed the package 5. /usr/local/libexec/ipsec/charon Plugin failed. Applied /usr/include/openssl/opensslv.h patch (below) for OPENSSL_VERSION_NUMBER changes and modified my make.conf to include CFLAGS+= -DOPENSSL_IS_LIBRESSL Same failure result. With openssl (not libressl), strongswan 5.6.0 builds and runs. Patch applied was restated from https://github.com/opnsense/ports/commit/d76955f3d #define LIBRESSL_VERSION_TEXT "LibreSSL 2.5.5" /* These will never change */ #ifndef OPENSSL_IS_LIBRESSL #define OPENSSL_VERSION_NUMBER 0x20000000L /* Suggested by https://github.com/opnsense/ports/commit/d76955f3d */ #else #define OPENSSL_VERSION_NUMBER 0x1000107fL #endif /* OPENSSL_IS_LIBRESSL */ /* For libressl 2.5.5 this is/should be # define OPENSSL_VERSION_NUMBER 0x100020bfL */
Hi Dewayne, I haven't checked 5.6.0 yet. Is this specific to 5.6.0? The amd64 package for 5.3.3 you could try is here: https://pkg.opnsense.org/FreeBSD:11:amd64/17.7/experimental/All/strongswan-5.5.3.txz Cheers, Franco
(In reply to Franco Fichtner from comment #30) Much appreciated Franco, but we build everything from source for our clients. I'm afraid with the passage of time, I can't say if its specific to strongswan 5.6.0. Though we had a problem using the base clang 5.0.0 (on FreeBSD11.1S) with qsort_r configure: error: qsort_r has unknown semantics but we successfully built with gcc6 (6.4.0). Sadly we're migrating back to openssl.
We have strongswan version 5.8.0. Is this still relevant?
Yes, but it is more of a StrongSwan shortcoming than anything that easily fixes since the ifdefs in the code are not very precise and quite frequent...
I guess we can close this as upstream doesn't seem to have any interest to support LibreSSL, objections?
(In reply to Daniel Engberg from comment #34) Thanks for reviewing Daniel and seeking input. :) I've reverted to openssl a while back, this probably needs a "closed-wont fix" status due to strongswan dev's position re non-openssl support.
I agree. We still use LibreSSL with StrongSwan on OPNsense but it was discontinued and won't be available in 2023. LibreSSL adoption as a whole is on a steady decline. Cheers, Franco
I abandoned an idea to compile local repository against LibreSSL long ago as more and more incompatibilities was discovered, so probably, we can close this.
Upstream have no interest in supporting LibreSSL (ref https://wiki.strongswan.org/issues/2165) so there's nothing to "fix".
^Triage: Assign to committer that resolves, correct resolution