Project

General

Profile

Feature #2165

missing LIBRESSL_VERSION_NUMBER support

Added by Franco Fichtner about 4 years ago. Updated about 4 years ago.

Status:
Feedback
Priority:
Normal
Assignee:
-
Category:
-
Target version:
-
Start date:
02.11.2016
Due date:
Estimated time:
Resolution:

Description

Hi,

This is a report over from FreeBSD ports for the following issue:

charon: 05[IKE] configured DH group MODP_3072 not supported

No IPsec connections can be established.

This seems to be related extensive OPENSSL_VERSION_NUMBER checking, which in LibreSSL is fixed to 0x20000000L, way past what OpenSSL actually uses as versions. Apparently, the choices that the code makes around these ifdefs results in a defunct state.

The "fix" is to fake a working number with the following patch, which was bundled with FreeBSD ports for a while, but recently dropped:

https://github.com/opnsense/ports/commit/7e8ea59ca

However, this shouldn't be fixed in LibreSSL as it has its own LIBRESSL_VERSION_NUMBER. Support for these checks in strongSwan itself are desired.

Original report: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=212149
Versions: 5.5.0+

Cheers,
Franco

History

#1 Updated by Tobias Brunner about 4 years ago

  • Tracker changed from Bug to Feature
  • Status changed from New to Feedback

This seems to be related extensive OPENSSL_VERSION_NUMBER checking, which in LibreSSL is fixed to 0x20000000L, way past what OpenSSL actually uses as versions.

These version checks are there to handle different variants of several functions and structs in newer OpenSSL versions (e.g. because structs were made opaque). It was easier to check the version than adding elaborate configure checks. Setting OPENSSL_VERSION_NUMBER to such a high value will obviously only work if LibreSSL always supported the same API as the latest OpenSSL version. Since that is unlikely to be the case they shouldn't have defined that constant at all (or only to the lowest version they are compatible with). I don't know LibreSSL at all so I have no idea how they modified the API and how or even whether any reasonable level of compatibility can be achieved with our code that's clearly geared towards OpenSSL (and BoringSSL to some degree as we use that on Android).

I don't agree with your assessment that we should be the ones to fix this. The LibreSSL user base is pretty small so if you want support for it please add it yourself and submit your patches for integration. I also don't really see how this is meant to work out in the future when these libraries diverge more and more. So maybe we just won't be compatible with LibreSSL and if you don't want to use OpenSSL you just have to rely on the built-in crypto plugins.

#2 Updated by Franco Fichtner about 4 years ago

Hi Tobias,

Thanks! Is the built-in crypto a compile or runtime option? Meaning if we build for e.g. OpenSSL, can we still use the built-in crypto in the same binary?

For going forward in FreeBSD, it remains inevitable to be providing patches specifically tailored for strongSwan one way or the other, but I'll ask all parties (including LibreSSL) if we can opt for a more portable solution in the mid-term future that also benefits strongSwan.

Cheers,
Franco

#3 Updated by Tobias Brunner about 4 years ago

Is the built-in crypto a compile or runtime option? Meaning if we build for e.g. OpenSSL, can we still use the built-in crypto in the same binary?

Both. The compile time options enable the plugins that implement the respective algorithms. These plugins may then be loaded at runtime in varying configurations to use different implementations (ipsec listalgs or swanctl --list-algs show which algorithms are provided by which plugin). One of the main features of the openssl plugin is support for ECC (ECDSA, ECDH), which is not provided by any of the other plugins. However, support for ECDH with Curve25519 will soon be provided by the plugin of the same name.

For going forward in FreeBSD, it remains inevitable to be providing patches specifically tailored for strongSwan one way or the other, but I'll ask all parties (including LibreSSL) if we can opt for a more portable solution in the mid-term future that also benefits strongSwan.

Is FreeBSD going to switch to LibreSSL? Would definitely be great if it was easier to work with different *SSL libraries (like e.g. some kind of compatibility layer or at least a detailed documentation of the API differences).

Also available in: Atom PDF