FIPS and EPAS 14

Donald Kai
Donald Kai

Currently there is a known issue regarding initialization failure in FIPS-enabled environments running EPAS 14.1 through 14.5. The resolution is to upgrade EPAS to 14.6. The purpose of this KB is to provide context surrounding the FIPS+EPAS issue and demonstrate known error messages.

Current state/Background

  1. PostgreSQL 14 started using OpenSSL EVP API for all hash computations, as described in PostgreSQL 14 Release notes, which allows compliance with FIPS. Previous versions use an internal implementation as fallback.
  2. MD5 itself is not an algorithm covered by FIPS compliance, as described by NIST FIPS 140-2 Security Policy in page 15: "MD5 is not a FIPS approved algorithm and therefore considered no more secure than plaintext."
  3. Consequently, password_encryption=md5 is not allowed in FIPS-enabled environments in an flavor (PG, PG Extended, EPAS). Likewise, md5 in pg_hba.conf cannot be used. Customers should use any other authentication method, with scram-sha-256 being the option directly in the same line as md5.
  4. EPAS uses MD5 as part of the EDB*WRAP feature for code obfuscation, which is invoked at initdb time in Redwood mode only, as well as in runtime if the customer calls a function wrapped with EDB*Wrap later. Note: Community PostgreSQL 14 and PostgreSQL Extended 14 are not affected except for md5 in the password and authentication rules.

Examples of Errors

The following are examples of error messages one may see when running EPAS 14.1 - 14.5 in FIPS-enabled environments

  • Example where the user tried to invoke initdb
PGSETUP_INITDB_OPTIONS="-E UTF-8" /usr/edb/as14/bin/edb-as-14-setup initdb
Initializing database ... failed, see /var/lib/edb/as14/initdb.log
...
dbms_aqadm.plb
2022-09-09 12:08:16 AEST FATAL: invalid wrapped string
2022-09-09 12:08:16 AEST STATEMENT: RESET search_path;
RESET ALL;
$__EDBwrapped__$
...
$__EDBwrapped__$
RESET ALL;
SET search_path = sys;

could not write to child process: Broken pipe
initdb: removing contents of data directory "/data/as14/edb"
  • Example where the instance was initialized and started, but tried to access a wrapped function
ERROR: EDB-20000: invalid wrapped string
CONTEXT: edb-spl function raise_application_error(numeric,text) line 14 at RAISE
  • Example where the user tried to set a password for a role using md5
alter user enterprisedb identified by 'pswd'; 
ERROR: password encryption failed

Resolution

The issue has been resolved with the release of EPAS 14.6, and is not present in any other major versions of EPAS, PostgreSQL Extended, or PostgreSQL.

Previous workarounds (No longer necessary, do not use)

EDB has developed a few workarounds for the customer to choose depending on their needs. Please read through each of them carefully and decide which one is best for the customer's implementation.

  • In EPAS 14, the instance can be initialized with FIPS enabled without Redwood mode. How to initialize the instance without Redwood mode.
  • In EPAS 14, the instance can be initialized with FIPS disabled, and in Redwood mode, then used later with FIPS enabled as long as the customer does not use EDB*Wrap.
  • In EPAS 14, the instance can be initialized in a different server (where FIPS is disabled), then the directory moved over; then used with FIPS enabled as long as the customer does not use EDB*Wrap.
  • If an existing EPAS 14 instance is already running on a server with FIPS disabled, then you can create a physical standby of that instance in a server with FIPS enabled. Once the standby is in sync, then the customer can promote the standby and point applications to it. This allows for a migration with low downtime, even for large databases. The promoted standby can then be used with FIPS enabled as long as the customer does not use EDB*Wrap.
  • EPAS 13, PG 14, and PG Extended can be used.

Was this article helpful?

0 out of 0 found this helpful