Re: Replace current implementations in crypt() and gen_salt() to OpenSSL - Mailing list pgsql-hackers

From Joe Conway
Subject Re: Replace current implementations in crypt() and gen_salt() to OpenSSL
Date
Msg-id 10eafdc8-1bde-41f9-9c3e-149d1ea97c65@joeconway.com
Whole thread Raw
In response to Re: Replace current implementations in crypt() and gen_salt() to OpenSSL  (Daniel Gustafsson <daniel@yesql.se>)
Responses Re: Replace current implementations in crypt() and gen_salt() to OpenSSL
List pgsql-hackers
On 12/4/24 10:01, Daniel Gustafsson wrote:
>> On 4 Dec 2024, at 15:52, Joe Conway <mail@joeconway.com> wrote:
>> 
>> On 12/4/24 09:45, Daniel Gustafsson wrote:
>>>> On 4 Dec 2024, at 15:40, Joe Conway <mail@joeconway.com> wrote:
>>>> On 12/4/24 09:33, Daniel Gustafsson wrote:
>>>>> since OpenSSL 1.1.1 cannot operate in FIPS mode.
>>>> I don't think that is correct. The RHEL 8 openssl which was FIPS 140-2 validated is 1.1.1k. See:
>>>>
https://csrc.nist.gov/CSRC/media/projects/cryptographic-module-validation-program/documents/security-policies/140sp4642.pdf
>>> Does RHEL publish the source of their fork somewhere?  In OpenSSL 1.1.1 the
>>> code for FIPS_mode is:
>>> int FIPS_mode(void)
>>> {
>>>     /* This version of the library does not support FIPS mode. */
>>>     return 0;
>>> }
>>> Do you know if RHEL patched OpenSSL to allow FIPS_mode() to return other than 0
>>> or if that function is useless regardless?
>> 
>> Yes the RHEL and OpenSUSE rpms for openssl are heavily patched for the FIPS versions, as is the Ubuntu one. It has
beena while but last time I looked at all of this they were all using very similar patches to allow the "system wide"
FIPSmode rather than depending on the app to explicitly go into FIPS_mode().
 
>> 
>> I can look for links, but investigating it involved (for example) installing the source rpm and then wading through
hundredsof patches in the SOURCE directory.
 

I can send you the source RPM for openssl 1.1.1c which was an earlier 
FIPS validated version, but the main FIPS patch contains:

8<-------------
diff -up openssl-1.1.1b/crypto/o_fips.c.fips openssl-1.1.1b/crypto/o_fips.c
--- openssl-1.1.1b/crypto/o_fips.c.fips    2019-02-26 15:15:30.000000000 +0100
+++ openssl-1.1.1b/crypto/o_fips.c    2019-02-28 11:30:06.817745466 +0100
@@ -8,17 +8,28 @@
   */

  #include "internal/cryptlib.h"
+#include "internal/fips_int.h"

  int FIPS_mode(void)
  {
+#ifdef OPENSSL_FIPS
+    return FIPS_module_mode();
+#else
      /* This version of the library does not support FIPS mode. */
      return 0;
+#endif
  }
8<-------------

> While I dislike not having a "follow-the-lib" setting on the GUC and rely on
> the transitive dependency, maybe that's the only option if we can't reliably
> detect the operating mode.  Sigh, as if OpenSSL wasn't messy enough even
> without vendor patches =)

Yep, that was my concern. I believe the RHEL, OpenSUSE, and Ubuntu 
solutions are very similar, but they may be different enough that it 
will be painful to reliably detect FIPS_mode. The RHEL and SUSE source 
RPMs were findable. I think to get the Ubuntu FIPS deb I had to pay for 
a subscription. But as I said it has been a while so I don't remember 
exactly (like 6+ years).

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



pgsql-hackers by date:

Previous
From: Bertrand Drouvot
Date:
Subject: Re: shared-memory based stats collector - v70
Next
From: Joe Conway
Date:
Subject: Re: Replace current implementations in crypt() and gen_salt() to OpenSSL