Bug 212149 - security/strongswan: Runtime failures with LibreSSL
Summary: security/strongswan: Runtime failures with LibreSSL
Status: Closed Works As Intended
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Some People
Assignee: Daniel Engberg
URL: https://wiki.strongswan.org/issues/2165
Keywords: needs-qa
Depends on:
Blocks:
 
Reported: 2016-08-25 14:59 UTC by Ivan
Modified: 2022-08-09 00:25 UTC (History)
8 users (show)

See Also:
bugzilla: maintainer-feedback? (strongswan)
koobs: merge-quarterly?


Attachments
build log (81.71 KB, application/gzip)
2016-09-24 14:17 UTC, Ivan
no flags Details
svn diff for security/strongswan (941 bytes, patch)
2017-04-20 19:37 UTC, Bernard Spil
no flags Details | Diff
svn diff for security/strongswan (4.31 KB, patch)
2017-04-21 07:37 UTC, Bernard Spil
no flags Details | Diff
Patch for RSA_set0_key and DH_set0_key (3.33 KB, patch)
2017-04-24 08:45 UTC, dewayne
no flags Details | Diff
libressl Makefile patch - helps migration to libressl (721 bytes, patch)
2017-04-25 02:22 UTC, dewayne
no flags Details | Diff
svn diff for security/strongswan (845 bytes, patch)
2017-04-25 20:32 UTC, Bernard Spil
no flags Details | Diff
svn diff for security/strongswan (21.78 KB, patch)
2017-04-25 20:34 UTC, Bernard Spil
brnrd: maintainer-approval?
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Ivan 2016-08-25 14:59:13 UTC
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.
Comment 1 Walter Schwarzenfeld freebsd_triage 2016-08-26 05:58:57 UTC
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.
Comment 2 Ivan 2016-08-26 06:49:11 UTC
(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.
Comment 3 Bernard Spil freebsd_committer freebsd_triage 2016-09-24 12:49:23 UTC
(In reply to Ivan from comment #0)
I would assume that there's improper linking (base vs ports).

Please provide build logs.
Comment 4 Ivan 2016-09-24 14:17:51 UTC
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
Comment 5 Franco Fichtner 2016-10-23 13:34:39 UTC
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
Comment 6 dewayne 2016-10-28 00:04:42 UTC
(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?
Comment 7 Franco Fichtner 2016-10-28 05:08:51 UTC
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.
Comment 8 Franco Fichtner 2016-11-02 11:24:33 UTC
Issue reported upstream: https://wiki.strongswan.org/issues/2165
Comment 9 dewayne 2017-04-12 21:08:40 UTC
(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
?
Comment 10 Franco Fichtner 2017-04-13 07:40:48 UTC
(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
Comment 11 Bernard Spil freebsd_committer freebsd_triage 2017-04-20 19:37:09 UTC
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...
Comment 12 dewayne 2017-04-21 05:08:10 UTC
(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
  */
Comment 13 Bernard Spil freebsd_committer freebsd_triage 2017-04-21 07:37:52 UTC
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.
Comment 14 dewayne 2017-04-24 08:45:17 UTC
Created attachment 182037 [details]
Patch for RSA_set0_key and DH_set0_key
Comment 15 dewayne 2017-04-24 08:54:27 UTC
(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.
Comment 16 Bernard Spil freebsd_committer freebsd_triage 2017-04-24 10:01:06 UTC
(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
Comment 17 dewayne 2017-04-25 02:22:37 UTC
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. ;)
Comment 18 dewayne 2017-04-25 02:27:48 UTC
(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.  :/
Comment 19 Bernard Spil freebsd_committer freebsd_triage 2017-04-25 20:32:48 UTC
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?
Comment 20 Bernard Spil freebsd_committer freebsd_triage 2017-04-25 20:34:11 UTC
Created attachment 182091 [details]
svn diff for security/strongswan

Sorry... That was output of svn status not svn diff.
Comment 21 dewayne 2017-04-26 21:18:26 UTC
(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 ;)
Comment 22 dewayne 2017-04-26 21:27:32 UTC
(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 */
Comment 23 Francois ten Krooden 2017-05-04 14:13:10 UTC
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.
Comment 24 Bernard Spil freebsd_committer freebsd_triage 2017-05-04 18:57:25 UTC
(In reply to strongswan from comment #23)
Waiting for Franco and Dewayne to report back on the patch.
Comment 25 Franco Fichtner 2017-05-05 06:26:28 UTC
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.
Comment 26 Franco Fichtner 2017-05-05 06:26:52 UTC
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.
Comment 27 Franco Fichtner 2017-08-03 07:30:04 UTC
Test of LibreSSL 2.5.5 on strongSwan 5.5.3 built from yesterday's ports: still doesn't work.
Comment 28 Franco Fichtner 2017-08-03 08:02:48 UTC
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
Comment 29 dewayne 2017-08-25 23:11:21 UTC
(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 */
Comment 30 Franco Fichtner 2017-08-26 07:07:44 UTC
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
Comment 31 dewayne 2017-10-04 04:23:11 UTC
(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.
Comment 32 Walter Schwarzenfeld freebsd_triage 2019-08-07 23:11:57 UTC
We have strongswan version 5.8.0. Is this still relevant?
Comment 33 Franco Fichtner 2019-12-16 07:22:11 UTC
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...
Comment 34 Daniel Engberg freebsd_committer freebsd_triage 2022-08-07 18:03:08 UTC
I guess we can close this as upstream doesn't seem to have any interest to support LibreSSL, objections?
Comment 35 dewayne 2022-08-07 23:54:55 UTC
(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.
Comment 36 Franco Fichtner 2022-08-08 07:47:42 UTC
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
Comment 37 Ivan 2022-08-08 15:10:46 UTC
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.
Comment 38 Daniel Engberg freebsd_committer freebsd_triage 2022-08-08 21:43:33 UTC
Upstream have no interest in supporting LibreSSL (ref https://wiki.strongswan.org/issues/2165) so there's nothing to "fix".
Comment 39 Kubilay Kocak freebsd_committer freebsd_triage 2022-08-09 00:25:06 UTC
^Triage: Assign to committer that resolves, correct resolution