Retire support for OpenSSL 1.1.1 due to raised API requirements
Commit a70e01d430 removed support for OpenSSL 1.0.2 in order to simplify the
code by removing the need for finicky initialization of the library. Based on
our API usage the new minimum version was defined as 1.1.0.
The patchset in https://commitfest.postgresql.org/49/5025/ which adds support
for configuring cipher suites in TLS 1.3 handshakes require an API available in
OpenSSL 1.1.1 and onwards. With that as motivation I'd like to propose that we
remove support for OpenSSL 1.1.0 and set the minimum required version to 1.1.1.
OpenSSL 1.1.0 was EOL in September 2019 and was never an LTS version, so it's
not packaged in anything anymore AFAICT and should be very rare in production
use in conjunction with an updated postgres. 1.1.1 LTS will be 2 years EOL by
the time v18 ships so I doubt this will be all that controversial.
The attached is the 0001 from the above mentioned patchset for illustration.
The removal should happen when pushing the rest of the patchset.
Does anyone see any reason not to go to 1.1.1 as the minimum?
--
Daniel Gustafsson
Attachments:
v5-0001-Raise-the-minimum-supported-OpenSSL-version-to-1..patchapplication/octet-stream; name=v5-0001-Raise-the-minimum-supported-OpenSSL-version-to-1..patch; x-unix-mode=0644Download
From e7a018f68d7a4abdd10343867694c8c57c9093a0 Mon Sep 17 00:00:00 2001
From: Daniel Gustafsson <dgustafsson@postgresql.org>
Date: Mon, 9 Sep 2024 12:35:29 +0200
Subject: [PATCH v5 1/3] Raise the minimum supported OpenSSL version to 1.1.1
Commit a70e01d4306fdbcd5f retired support for OpenSSL 1.0.2 in order get
rid of the need for manual initialization of the library . This left our
API usage compatible with 1.1.0 which was defined as the minimum required
version.
An upcoming commit will introduce support for configuring TLSv1.3 cipher
suites which require an API call in OpenSSL 1.1.1 and onwards. In order
to support this setting this commit will set v1.1.1 as the new minimum
required version. There is no function change in this commit, only build
infrastructure changes.
Author: Daniel Gustafsson <daniel@yesql.se>
Reviewed-by: TBD <tbd>
Discussion: https://postgr.es/m/tbd
Discussion: https://postgr.es/m/tencent_063F89FA72CCF2E48A0DF5338841988E9809@qq.com
---
configure | 16 ++++++++--------
configure.ac | 8 ++++----
doc/src/sgml/installation.sgml | 2 +-
meson.build | 6 +++---
src/include/pg_config.h.in | 6 +++---
5 files changed, 19 insertions(+), 19 deletions(-)
diff --git a/configure b/configure
index 53c8a1f2ba..e74839b76b 100755
--- a/configure
+++ b/configure
@@ -12313,9 +12313,9 @@ if test "$with_openssl" = yes ; then
fi
if test "$with_ssl" = openssl ; then
- # Minimum required OpenSSL version is 1.1.0
+ # Minimum required OpenSSL version is 1.1.1
-$as_echo "#define OPENSSL_API_COMPAT 0x10100000L" >>confdefs.h
+$as_echo "#define OPENSSL_API_COMPAT 0x10101000L" >>confdefs.h
if test "$PORTNAME" != "win32"; then
{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for CRYPTO_new_ex_data in -lcrypto" >&5
@@ -12542,21 +12542,21 @@ _ACEOF
fi
done
- # Functions introduced in OpenSSL 1.1.0. We used to check for
+ # Functions introduced in OpenSSL 1.1.1. We used to check for
# OPENSSL_VERSION_NUMBER, but that didn't work with 1.1.0, because LibreSSL
# defines OPENSSL_VERSION_NUMBER to claim version 2.0.0, even though it
# doesn't have these OpenSSL 1.1.0 functions. So check for individual
# functions.
- for ac_func in OPENSSL_init_ssl
+ for ac_func in SSL_CTX_set_ciphersuites
do :
- ac_fn_c_check_func "$LINENO" "OPENSSL_init_ssl" "ac_cv_func_OPENSSL_init_ssl"
-if test "x$ac_cv_func_OPENSSL_init_ssl" = xyes; then :
+ ac_fn_c_check_func "$LINENO" "SSL_CTX_set_ciphersuites" "ac_cv_func_SSL_CTX_set_ciphersuites"
+if test "x$ac_cv_func_SSL_CTX_set_ciphersuites" = xyes; then :
cat >>confdefs.h <<_ACEOF
-#define HAVE_OPENSSL_INIT_SSL 1
+#define HAVE_SSL_CTX_SET_CIPHERSUITES 1
_ACEOF
else
- as_fn_error $? "OpenSSL version >= 1.1.0 is required for SSL support" "$LINENO" 5
+ as_fn_error $? "OpenSSL version >= 1.1.1 is required for SSL support" "$LINENO" 5
fi
done
diff --git a/configure.ac b/configure.ac
index 6a35b2880b..68b41d60c1 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1314,8 +1314,8 @@ fi
if test "$with_ssl" = openssl ; then
dnl Order matters!
- # Minimum required OpenSSL version is 1.1.0
- AC_DEFINE(OPENSSL_API_COMPAT, [0x10100000L],
+ # Minimum required OpenSSL version is 1.1.1
+ AC_DEFINE(OPENSSL_API_COMPAT, [0x10101000L],
[Define to the OpenSSL API version in use. This avoids deprecation warnings from newer OpenSSL versions.])
if test "$PORTNAME" != "win32"; then
AC_CHECK_LIB(crypto, CRYPTO_new_ex_data, [], [AC_MSG_ERROR([library 'crypto' is required for OpenSSL])])
@@ -1326,12 +1326,12 @@ if test "$with_ssl" = openssl ; then
fi
# Function introduced in OpenSSL 1.0.2, not in LibreSSL.
AC_CHECK_FUNCS([SSL_CTX_set_cert_cb])
- # Functions introduced in OpenSSL 1.1.0. We used to check for
+ # Functions introduced in OpenSSL 1.1.1. We used to check for
# OPENSSL_VERSION_NUMBER, but that didn't work with 1.1.0, because LibreSSL
# defines OPENSSL_VERSION_NUMBER to claim version 2.0.0, even though it
# doesn't have these OpenSSL 1.1.0 functions. So check for individual
# functions.
- AC_CHECK_FUNCS([OPENSSL_init_ssl], [], [AC_MSG_ERROR([OpenSSL version >= 1.1.0 is required for SSL support])])
+ AC_CHECK_FUNCS([SSL_CTX_set_ciphersuites], [], [AC_MSG_ERROR([OpenSSL version >= 1.1.1 is required for SSL support])])
# Function introduced in OpenSSL 1.1.1, not in LibreSSL.
AC_CHECK_FUNCS([X509_get_signature_info SSL_CTX_set_num_tickets])
AC_DEFINE([USE_OPENSSL], 1, [Define to 1 to build with OpenSSL support. (--with-ssl=openssl)])
diff --git a/doc/src/sgml/installation.sgml b/doc/src/sgml/installation.sgml
index ff9abd4649..f88912e98d 100644
--- a/doc/src/sgml/installation.sgml
+++ b/doc/src/sgml/installation.sgml
@@ -293,7 +293,7 @@
encrypted client connections. <productname>OpenSSL</productname> is
also required for random number generation on platforms that do not
have <filename>/dev/urandom</filename> (except Windows). The minimum
- required version is 1.1.0.
+ required version is 1.1.1.
</para>
</listitem>
diff --git a/meson.build b/meson.build
index 4764b09266..471baa1ec4 100644
--- a/meson.build
+++ b/meson.build
@@ -1359,12 +1359,12 @@ if sslopt in ['auto', 'openssl']
['CRYPTO_new_ex_data', {'required': true}],
['SSL_new', {'required': true}],
- # Functions introduced in OpenSSL 1.1.0. We used to check for
+ # Functions introduced in OpenSSL 1.1.1. We used to check for
# OPENSSL_VERSION_NUMBER, but that didn't work with 1.1.0, because LibreSSL
# defines OPENSSL_VERSION_NUMBER to claim version 2.0.0, even though it
# doesn't have these OpenSSL 1.1.0 functions. So check for individual
# functions.
- ['OPENSSL_init_ssl', {'required': true}],
+ ['SSL_CTX_set_ciphersuites', {'required': true}],
# Function introduced in OpenSSL 1.0.2, not in LibreSSL.
['SSL_CTX_set_cert_cb'],
@@ -1393,7 +1393,7 @@ if sslopt in ['auto', 'openssl']
if are_openssl_funcs_complete
cdata.set('USE_OPENSSL', 1,
description: 'Define to 1 to build with OpenSSL support. (-Dssl=openssl)')
- cdata.set('OPENSSL_API_COMPAT', '0x10100000L',
+ cdata.set('OPENSSL_API_COMPAT', '0x10101000L',
description: 'Define to the OpenSSL API version in use. This avoids deprecation warnings from newer OpenSSL versions.')
ssl_library = 'openssl'
else
diff --git a/src/include/pg_config.h.in b/src/include/pg_config.h.in
index 38006367a4..aa5a77b985 100644
--- a/src/include/pg_config.h.in
+++ b/src/include/pg_config.h.in
@@ -286,9 +286,6 @@
/* Define to 1 if you have the `mkdtemp' function. */
#undef HAVE_MKDTEMP
-/* Define to 1 if you have the `OPENSSL_init_ssl' function. */
-#undef HAVE_OPENSSL_INIT_SSL
-
/* Define to 1 if you have the <ossp/uuid.h> header file. */
#undef HAVE_OSSP_UUID_H
@@ -364,6 +361,9 @@
/* Define to 1 if you have the `SSL_CTX_set_cert_cb' function. */
#undef HAVE_SSL_CTX_SET_CERT_CB
+/* Define to 1 if you have the `SSL_CTX_set_ciphersuites' function. */
+#undef HAVE_SSL_CTX_SET_CIPHERSUITES
+
/* Define to 1 if you have the `SSL_CTX_set_num_tickets' function. */
#undef HAVE_SSL_CTX_SET_NUM_TICKETS
--
2.39.3 (Apple Git-146)
Daniel Gustafsson <daniel@yesql.se> writes:
The patchset in https://commitfest.postgresql.org/49/5025/ which adds support
for configuring cipher suites in TLS 1.3 handshakes require an API available in
OpenSSL 1.1.1 and onwards. With that as motivation I'd like to propose that we
remove support for OpenSSL 1.1.0 and set the minimum required version to 1.1.1.
OpenSSL 1.1.0 was EOL in September 2019 and was never an LTS version, so it's
not packaged in anything anymore AFAICT and should be very rare in production
use in conjunction with an updated postgres. 1.1.1 LTS will be 2 years EOL by
the time v18 ships so I doubt this will be all that controversial.
Yeah ... the alternative would be to conditionally compile the new
functionality. That doesn't seem like a productive use of developer
time if it's supporting just one version that should be extinct in
the wild by now.
regards, tom lane
On 9 Sep 2024, at 16:48, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Daniel Gustafsson <daniel@yesql.se> writes:
The patchset in https://commitfest.postgresql.org/49/5025/ which adds support
for configuring cipher suites in TLS 1.3 handshakes require an API available in
OpenSSL 1.1.1 and onwards. With that as motivation I'd like to propose that we
remove support for OpenSSL 1.1.0 and set the minimum required version to 1.1.1.
OpenSSL 1.1.0 was EOL in September 2019 and was never an LTS version, so it's
not packaged in anything anymore AFAICT and should be very rare in production
use in conjunction with an updated postgres. 1.1.1 LTS will be 2 years EOL by
the time v18 ships so I doubt this will be all that controversial.Yeah ... the alternative would be to conditionally compile the new
functionality. That doesn't seem like a productive use of developer
time if it's supporting just one version that should be extinct in
the wild by now.
Agreed. OpenSSL 1.1.1 is very different story and I suspect we'll be stuck on
that level for some time, but 1.1.0 is gone from production use.
--
Daniel Gustafsson
On Mon, Sep 09, 2024 at 11:29:09PM +0200, Daniel Gustafsson wrote:
Agreed. OpenSSL 1.1.1 is very different story and I suspect we'll be stuck on
that level for some time, but 1.1.0 is gone from production use.
The cleanup induced by the removal of 1.1.0 is minimal. I'm on board
about your argument with SSL_CTX_set_ciphersuites() to drop 1.1.0 and
simplify the other feature.
I was wondering about HAVE_SSL_CTX_SET_NUM_TICKETS for a few seconds,
but morepork that relies on LibreSSL 3.3.2 disagrees with me.
--
Michael
On 10 Sep 2024, at 00:53, Michael Paquier <michael@paquier.xyz> wrote:
On Mon, Sep 09, 2024 at 11:29:09PM +0200, Daniel Gustafsson wrote:
Agreed. OpenSSL 1.1.1 is very different story and I suspect we'll be stuck on
that level for some time, but 1.1.0 is gone from production use.The cleanup induced by the removal of 1.1.0 is minimal. I'm on board
about your argument with SSL_CTX_set_ciphersuites() to drop 1.1.0 and
simplify the other feature.
Yeah, the change to existing code is trivial but avoiding adding a kluge to
handle versions without the relevant API will save complexity. Thanks for
review.
This change will be committed together with the TLSv1.3 cipher suite pathcset,
just wanted to bring it up here and not hide it in another thread.
--
Daniel Gustafsson
On Tue, Sep 10, 2024 at 10:44:42AM +0200, Daniel Gustafsson wrote:
This change will be committed together with the TLSv1.3 cipher suite pathcset,
just wanted to bring it up here and not hide it in another thread.
As you wish ;)
--
Michael
On 10 Sep 2024, at 10:44, Daniel Gustafsson <daniel@yesql.se> wrote:
This change will be committed together with the TLSv1.3 cipher suite pathcset,
just wanted to bring it up here and not hide it in another thread.
In the TLSv1.3 cipher suite thread it was brought up that this bump in minimum
version would bump the minimum version of libressl to 3.4, whcih corresponds to
the OpenBSD 3.4 release (from October 2021). The OpenBSD project only supports
the two last releases (7.7 will be the latest by the time v18 ships it seems)
and I assume LibreSSL follows that since they don't state anything else AFAICT.
To keep this from being buried on another thread I figured I'd bring it up here
as well.
We don't explicitly mention which libressl version we support, if we raise it
as proposed here then perhaps it's a good time to state that in the docs.
--
Daniel Gustafsson
On Thu, Oct 3, 2024 at 3:17 AM Daniel Gustafsson <daniel@yesql.se> wrote:
In the TLSv1.3 cipher suite thread it was brought up that this bump in minimum
version would bump the minimum version of libressl to 3.4, whcih corresponds to
the OpenBSD 3.4 release (from October 2021).
OpenBSD 7.0, that is.
We don't explicitly mention which libressl version we support, if we raise it
as proposed here then perhaps it's a good time to state that in the docs.
+1
--Jacob
On Thu, Oct 03, 2024 at 08:54:49AM -0700, Jacob Champion wrote:
On Thu, Oct 3, 2024 at 3:17 AM Daniel Gustafsson <daniel@yesql.se> wrote:
We don't explicitly mention which libressl version we support, if we raise it
as proposed here then perhaps it's a good time to state that in the docs.+1
It's pretty clear that we are maintaining it, so +1 to do that and
also mention that libressl falls under the --with-ssl=openssl flag.
--
Michael
This has now been committed via the TLS 1.3 ciphersuite patchset.
--
Daniel Gustafsson