Re: Replace current implementations in crypt() and gen_salt() to OpenSSL

From: Joe Conway <mail(at)joeconway(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Daniel Gustafsson <daniel(at)yesql(dot)se>
Cc: "Koshi Shibagaki (Fujitsu)" <shibagaki(dot)koshi(at)fujitsu(dot)com>, "Hayato Kuroda (Fujitsu)" <kuroda(dot)hayato(at)fujitsu(dot)com>, Peter Eisentraut <peter(at)eisentraut(dot)org>, Robert Haas <robertmhaas(at)gmail(dot)com>, "pgsql-hackers(at)lists(dot)postgresql(dot)org" <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Replace current implementations in crypt() and gen_salt() to OpenSSL
Date: 2025-01-21 21:13:26
Message-ID: a7a745fc-89b7-4185-9025-b5ac7f1acaae@joeconway.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 1/21/25 15:59, Tom Lane wrote:
> Daniel Gustafsson <daniel(at)yesql(dot)se> writes:
>> It could indeed be useful, but I doubt we can make it portable to check for
>> anything but the state of OpenSSL. If the operating system has a FIPS mode
>> then we won't capture that. That might not be a problem since if the OS is in
>> FIPS mode then OpenSSL most likely will be too but we can't guarantee it.
>
> Not our problem, I think. The OS vendor would have to have fallen
> down on the job quite badly to offer an OS-level "FIPS mode" while
> shipping an OpenSSL that doesn't honor that. It would not be optional
> for OpenSSL to be in that mode if the OS is.
>
> (If we end up inventing a FIPS-mode flag, I would fully expect
> interested vendors to patch our code to force it on when the
> OS-level flag is set, which is exactly what they will have done
> to OpenSSL. We should design our behavior with that in mind.)

I think this is a non-issue. Every implementation I have seen, the
OS-level enabling of FIPS mode is just a way to ensure openssl is
automatically put into FIPS mode when the library is loaded, just as if
(and not depending on) the application had invoked FIPS mode manually.
All matters here is that the loaded openssl thinks it is in FIPS mode.

I think that could be done with a subset of the proposed
CheckBuiltinCryptoMode() function. E.g. something like (completely
untested):

8<----------------------
+ /*
+ * CheckFIPSMode
+ *
+ * Function to determine if OpenSSL is operating in FIPS mode
+ */
+ int
+ CheckFIPSMode(void)
+ {
+ int fips_enabled;
+
+ /*
+ * EVP_default_properties_is_fips_enabled was added in OpenSSL 3.0,
before
+ * that FIPS_mode() was used to test for FIPS being enabled. The last
+ * upstream OpenSSL version before 3.0 which supported FIPS was
1.0.2, but
+ * there are forks of 1.1.1 which are FIPS certified so we still need to
+ * test with FIPS_mode() even though we don't support 1.0.2.
+ */
+ fips_enabled =
+ #if OPENSSL_VERSION_NUMBER >= 0x30000000L
+ EVP_default_properties_is_fips_enabled(NULL);
+ #else
+ FIPS_mode();
+ #endif
+
+ return fips_enabled;
+ }
8<-----------------

The we could call CheckFIPSMode() from CheckBuiltinCryptoMode() as well
as from a SQL-level wrapper.

--
Joe Conway
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Oliver Ford 2025-01-21 21:14:55 Re: Add RESPECT/IGNORE NULLS and FROM FIRST/LAST options
Previous Message Álvaro Herrera 2025-01-21 21:06:14 Re: Allow NOT VALID foreign key constraints on partitioned tables.