> On 24 Sep 2020, at 04:53, Michael Paquier <mich...@paquier.xyz> wrote:
> Enabling FIPS with OpenSSL 1.0.2 causes direct calls to the SHAXXX > routines to fail: > "Low level API call to digest SHA256 forbidden in fips mode" Confirmed by running 1.0.2s-fips with fips_mode=yes in the alg_section in openssl.cnf. > This got discussed back in 2018, but I never got back to it: > https://www.postgresql.org/message-id/20180911030250.ga27...@paquier.xyz > > One thing I did not like back in the past patch was that we did not > handle failures if one of OpenSSL's call failed, but this can easily > be handled by using a trick similar to jsonapi.c to fail hard if that > happens. > > It is worth noting that the low-level SHA routines are not recommended > for years in OpenSSL, and that these have been officially marked as > deprecated in 3.0.0. So, while the changes in sha2.h don't make this > stuff back-patchable per the ABI breakage it introduces, switching > sha2_openssl.c to use EVP is a better move in the long term, Agreed. Commit 5ff4a67f63f [0] moved contrib/pgcrypto from using low-level functions for pretty much exactly the same reasons: they are advised against and break FIPS. With your patch I can run the SSL tests successfully both with and without FIPS. I'm in favor of moving to the EVP API. > ..even if > that means that SCRAM+FIPS would not work with PG 10~13, so the > attached is something for HEAD, even if this would be possible to do > in older releases as the routines used in the attached are available > in versions of OpenSSL older than 1.0.1. Thats kind of a shame, but given the low volume of reports to -bugs and -hackers, the combination SCRAM and FIPS might not be all too common. Since OpenSSL FIPS is EOL it might also not increase until 3.0.0 comes with FIPS certification? If we really want to support it (which would require more evidence of it being a problem IMO), using the non-OpenSSL sha256 code would be one option I guess? cheers ./daniel [0] https://postgr.es/m/561274f1.1030...@iki.fi
