From: Heikki Linnakangas <hlinnaka@iki.fi>
To: Michael Paquier <michael@paquier.xyz>
Cc: gunnar.bluth@pro-open.de, pgsql-bugs@lists.postgresql.org, Jacob Champion <jchampion@timescale.com>
Subject: Re: BUG #17760: SCRAM authentication fails with "modern" (rsassaPss signature) server certificate
Date: Thu, 9 Feb 2023 23:54:37 +0200
Message-ID: <07e810b5-ea15-87ac-1745-e765e426062e@iki.fi> (raw)
In-Reply-To: <Y+St0GKY9FsTTJ1U@paquier.xyz>
References: <17760-b6c61e752ec07060@postgresql.org>
<b27b9b96-ea65-2ed1-d632-c5ab55713b06@iki.fi>
<584842ed-e476-6bac-bb36-2aec204e9eef@iki.fi>
<Y+St0GKY9FsTTJ1U@paquier.xyz>
On 09/02/2023 10:24, Michael Paquier wrote:
> It seems so wrong to me that we would just silently disable this
> feature because RSA-PSS does not give you an algo type to do the
> computation work. I'll try to look at bit at the OpenSSL code base
> and see if we could not extract the algo information in this case.
> Unfortunately, RFC 5929 is very clear:
> "if the certificate's signatureAlgorithm uses no hash functions or
> uses multiple hash functions, then this channel binding type's
> channel bindings are undefined at this time (updates to is channel
> binding type may occur to address this issue if it ever arises)."
>
> I understand from this sentence that if a certificate has no hash
> functions, then there's nothing you can do about it.
>
> So as much as I'd like to be aggressive and potentially enforce the
> use of SHA256 to compute the certificate hash, what you are doing is
> RFC-compliant.
Yeah, it seems silly to use anything else than SHA-256, given that
SCRAM-SHA-256 is totally dependent on the security of SHA-256 anyway.
Reading RFC5929 section "10.1. Cryptographic Algorithm Agility" [1], I
think the idea behind deriving the hash algorithm from the certificate's
signature algorithm is to allow the algorithm to be upgraded
automatically as new certificates with stronger algorithms are
introduced. But again, that seems silly with SCRAM-SHA-256.
I'm a little uncomfortable with this patch as I wrote it. It's not
trivial. The LOG messages might not be seen by admins. If we add a GUC
as you suggested, then an admin might need to change the GUC as part of
a minor version upgrade, or the server will refuse to start up. And we
cannot do anything about the client. And with all of this, we still
won't actually support channel binding with those certificates.
Perhaps we should just ignore the RFC and use SHA256 for these known
"undef" cases, after all. Having slept over this, I feel that would be
the best option. What do you think?
We could use a new "tls-server-end-point-sha-256" channel binding name
for that, instead of "tls-server-end-point", to make it clear when we're
violating the RFC.
[1] https://www.rfc-editor.org/rfc/rfc5929#section-10.1
- Heikki
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-bugs@postgresql.org
Cc: hlinnaka@iki.fi, michael@paquier.xyz, jchampion@timescale.com
Subject: Re: BUG #17760: SCRAM authentication fails with "modern" (rsassaPss signature) server certificate
In-Reply-To: <07e810b5-ea15-87ac-1745-e765e426062e@iki.fi>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox