OpenSSL 1.1.1 EOL September 2023 - any advice on moving to OpenSSL 3.0?

R

richardtoohey2

Is anyone using OpenSSL 3.0?

With ports? If so, how?

Any advice or things to watch out for?

In particular FreeBSD 13.2 amd64, and using Apache 2.4, PHP 8.1/8.2 and MySQL 8.0.
 
  • Thanks
Reactions: _al
With this in /etc/make.conf:
Code: 
DEFAULT_VERSIONS+=ssl=openssl30
I had no (obvious) trouble building Apache 2.4, MySQL 8.0.32, and PHP 8.2.5. Need to do a lot more to actually test all of them, but the basic building worked with the latest ports tree.
 
Yesterday I built (on FreeBSD 13.2-RELEASE, Debian 11, Windows 10 Pro) openssl 3.0.8 and gost-engine. Then I rebuilt all my working sources on these systems. Nothing has been edited anywhere. Everything is working. It seems that the API has not changed (until yesterday I used openssl 1.1.1j , I do not use openssl as a utility - I use it as a library).

Edit. For my work, I do not use openssl from pkg/ports, because I change something in the original openssl sources - I add algorithms specific to the needs of customer systems. Algorithms are added directly to the code rather than plugged in as external Engines (gost-engine is used in both ways). My job is to prototype customer systems. The customer receives a prototype of the system in source code.
 
Apache and PHP (mod_php) 8.1 seem happy, MySQL builds (I'm not using with OpenSSL on this machine), vsftpd is the only thing that won't build (but if I untick the SSL option it will at least build).
Code: 
Apache/2.4.57 (FreeBSD) OpenSSL/3.0.9-dev PHP/8.1.18
Obviously not a through test, nor one involving any corner cases, not checking performance but so far at least Apache with mod_php is building and running.
 
_al said:
...It seems that the API has not changed...
Click to expand...
I rushed with this. Many interface functions are deprecated now, for instance:
Bash: 
 [lanin@freebsd ~/inst/openssl-3.0.8]$ grep -R OSSL_DEPRECATEDIN_3_0 --include=*.h .
...
 ./include/openssl/ec.h:OSSL_DEPRECATEDIN_3_0 int EC_GROUP_get_curve_GFp(const EC_GROUP *group,
./include/openssl/ec.h:OSSL_DEPRECATEDIN_3_0 int EC_GROUP_set_curve_GF2m(EC_GROUP *group,
...

My old code builds successfully, but terminal is full of messages like:
Bash: 
 warning: 'EC_KEY_new' is deprecated: Since OpenSSL 3.0 [-Wdeprecated-declarations]
 warning: 'EC_KEY_free' is deprecated: Since OpenSSL 3.0 [-Wdeprecated-declarations]
 warning: 'EC_POINT_set_affine_coordinates_GF2m' is deprecated: Since OpenSSL 3.0 [-Wdeprecated-declarations]
 
Are people using this commonly yet?

Am surprised I had no warnings from the ports tree (which usually moans a lot when upcoming EOL is coming) and then realised not long ago 1.1.1 is now EOL.

Yet I assume future builds of 13.x will have it in base still and the ports tree still points to 1.1.1 by default.

I am expecting due to the lack of movement in either the default openssl in ports or base, this is kind of a last minute switcheroo and if I just switch to openssl30 a bunch of ports will have problems.
 
chrcol said:
Yet I assume future builds of 13.x will have it in base still and the ports tree still points to 1.1.1 by default.
Click to expand...
The issue is, this isn't possible without breaking ABI or having two different OpenSSL versions (one private) in base, which has other hard to solve issues. See also what Alexander wrote in the thread: https://lists.freebsd.org/archives/freebsd-arch/2023-April/000365.html -- I fully agree with him.

Now, this discussion was half a year ago. 14 already moved to OpenSSL 3 (before entering release engineering). A lot of fixing in ports was done as well, ports should largely build and work with OpenSSL 3 from base now.

I honestly don't know what's the plan now for stable/13. One could always try the "Debian approach" and backport security fixes yourself, which is very tedious and also error-prone work... not sure whether this is considered. People actively working on base probably know more.

From a user perspective, I'd say the best way to avoid this issue is to move to 14.0-RELEASE early on.
 
zirias@ said:
From a user perspective, I'd say the best way to avoid this issue is to move to 14.0-RELEASE early on.
Click to expand...
One of the real differentiators of Freebsd for me is the fact that it does not put you on an upgrade treadmill. I will not be "upgrading" to any .0 versions, ever. I'll take my chances with the old Openssl.

I do wish Ed Maste's suggestion to make SSL in base a private lib could've been implemented for 14. The Openssl folks are going the Python way and hating on their users.
 
Jose said:
One of the real differentiators of Freebsd for me is the fact that it does not put you on an upgrade treadmill. I will not be "upgrading" to any .0 versions, ever. I'll take my chances with the old Openssl.
Click to expand...
And nothing changed about that, you're still not forced to upgrade early on. I wrote "the best way to avoid the issue", which in the context of this thread means, if you're worried about the security of an EOL OpenSSL version, this is probably what you should do.
Jose said:
I do wish Ed Maste's suggestion to make SSL in base a private lib could've been implemented for 14.
Click to expand...
This would be a massive change. It would indeed solve this problem, as soon as OpenSSL isn't part of FreeBSD's ABI any more, it's decoupled from the support cycle and could even be upgraded in a patch level. OTOH, it would mean you'd always need another OpenSSL (or compatible) from ports.
 
I've not really been following this but it sounds like:
openssl3.x abi breaks everything using openssl1.x abi?

If so, regardless of "why":
Is there anyway to redefine the openssl 1.x abi as a macro to fit the openssl3.x abi?
Yes, suboptimal, but perhaps a way to bridge the gap?

I think flipping openssl versions in Makefiles means that source code for a port needs to have #ifdef openssl3 #else #endif all over the place.

binary compat is also affected in theory.
 
chrcol said:
I am expecting due to the lack of movement in either the default openssl in ports or base, this is kind of a last minute switcheroo and if I just switch to openssl30 a bunch of ports will have problems.
Click to expand...
Only on development machines (servers) so far, but Apache, PHP/mod_php and MySQL (just built with OpenSSL 3 not knowingly using it) on amd64 13.2-RELEASE p4 - everything is building and seems happy with DEFAULT_VERSIONS+=ssl=openssl30 in /etc/make.conf.

Previously seen issues with vsftpd and libfido2 but the developers (thank you!) seem to have fixed those.

I'm not ready to try this on production and want to try a FreeBSD 14.0 install soon to compare against - but so far looking like it might fly (OpenSSL 3.0 on 13.2 using ports).
 
You must log in or register to reply here.
Back
Top