Re: scram-sha-256 authentication broken in FIPS mode - Mailing list pgsql-general
| From | Alessandro Gherardi |
|---|---|
| Subject | Re: scram-sha-256 authentication broken in FIPS mode |
| Date | |
| Msg-id | 767499000.1481233.1536153579656@mail.yahoo.com Whole thread Raw |
| In response to | Re: scram-sha-256 authentication broken in FIPS mode (Michael Paquier <michael@paquier.xyz>) |
| Responses |
Re: scram-sha-256 authentication broken in FIPS mode
(Michael Paquier <michael@paquier.xyz>)
|
| List | pgsql-general |
Hi Michael,
I'm actually running postgres on Windows.
I added code to fe-secure-openssl.c and be-secure-openssl.c that reads the Windows "standard" FIPS registry entry, and if FIPS is enabled calls FIPS_mode_set(1). This is to mimic to behavior of the .NET framework.
Below is the code I added to fe-secure-openssl.c, the code in be-secure-openssl.c is similar:
Thoughts? I can try to fix the scram-sha-256 issue by using EVP and send you a merge request for the patch and the code below if you think my approach is correct.
Thanks,
Alessandro
int
pgtls_init(PGconn *conn)
{
...
if (!ssl_lib_initialized)
{
if (pq_init_ssl_lib)
{
#ifdef WIN32
HKEY rootKey;
DWORD fipsEnabled = 0;
DWORD fipsEnabledSize = sizeof(DWORD);
if (RegOpenKeyEx(HKEY_LOCAL_MACHINE,
"System\\CurrentControlSet\\Control\\Lsa\\FipsAlgorithmPolicy",
0,
KEY_READ,
&rootKey) != ERROR_SUCCESS)
{
printfPQExpBuffer(&conn->errorMessage,
libpq_gettext("could not open FIPS registry key"));
return -1;
}
if (RegQueryValueEx(rootKey,
"Enabled",
0,
0,
(LPBYTE) &fipsEnabled,
&fipsEnabledSize) != ERROR_SUCCESS)
{
RegCloseKey(rootKey);
printfPQExpBuffer(&conn->errorMessage,
libpq_gettext("could not read FIPS registry entry"));
return -1;
}
RegCloseKey(rootKey);
if (fipsEnabled == 1 && FIPS_mode() == 0)
{
if (FIPS_mode_set(1) != 1)
{
printfPQExpBuffer(&conn->errorMessage,
libpq_gettext("could not enable FIPS mode"));
return -1;
}
}
#endif
#ifdef HAVE_OPENSSL_INIT_SSL
OPENSSL_init_ssl(OPENSSL_INIT_LOAD_CONFIG, NULL);
#else
OPENSSL_config(NULL);
SSL_library_init();
SSL_load_error_strings();
#endif
On Tuesday, September 4, 2018, 10:27:22 PM MDT, Michael Paquier <michael@paquier.xyz> wrote:
On Wed, Sep 05, 2018 at 03:29:31AM +0000, Alessandro Gherardi wrote:
> It looks like scram-sha-256 doesn't work when postgres is linked
> against FIPS-enabled OpenSSL and FIPS mode is turned on.
>
> Specifically, all login attempts fail with an OpenSSL error saying
> something along the lines of "Low level API call to digest SHA256
> forbidden in fips mode".
The error comes from libc, right? Postgres can of course be configured
to work with FIPS without patching it, it just needs to be enabled
system-wide, which is what RedHat does, and what you are doing I guess?
> I think this issue could be solved by refactoring the code in
> sha2_openssl.c to use the OpenSSL EVP interface
> (see https://wiki.openssl.org/index.php/EVP_Message_Digests ).
> Any thoughts? Is this a known issue?
This report is the first of this kind since Postgres 10, which is where
the SHA2 interface for OpenSSL has been introduced. So likely we'd need
to look into that more deeply.. This has the strong smell of a bug. If
your system is new enough, you should have sha256() & co as system
functions, so you would see the failure as well? The regression tests
would have likely complained.
--
Michael
> It looks like scram-sha-256 doesn't work when postgres is linked
> against FIPS-enabled OpenSSL and FIPS mode is turned on.
>
> Specifically, all login attempts fail with an OpenSSL error saying
> something along the lines of "Low level API call to digest SHA256
> forbidden in fips mode".
The error comes from libc, right? Postgres can of course be configured
to work with FIPS without patching it, it just needs to be enabled
system-wide, which is what RedHat does, and what you are doing I guess?
> I think this issue could be solved by refactoring the code in
> sha2_openssl.c to use the OpenSSL EVP interface
> (see https://wiki.openssl.org/index.php/EVP_Message_Digests ).
> Any thoughts? Is this a known issue?
This report is the first of this kind since Postgres 10, which is where
the SHA2 interface for OpenSSL has been introduced. So likely we'd need
to look into that more deeply.. This has the strong smell of a bug. If
your system is new enough, you should have sha256() & co as system
functions, so you would see the failure as well? The regression tests
would have likely complained.
--
Michael
pgsql-general by date: