From: Heikki Linnakangas <hlinnaka@iki.fi>
To: Michael Paquier <michael@paquier.xyz>
Cc: Jacob Champion <jchampion@timescale.com>
Cc: gunnar.bluth@pro-open.de
Cc: pgsql-bugs@lists.postgresql.org
Subject: Re: BUG #17760: SCRAM authentication fails with "modern" (rsassaPss signature) server certificate
Date: Fri, 10 Feb 2023 11:33:44 +0200
Message-ID: <687f8e73-e511-6994-c2e2-3cc55633fab6@iki.fi> (raw)
In-Reply-To: <Y+Xk8N/atQixeE2/@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>
<07e810b5-ea15-87ac-1745-e765e426062e@iki.fi>
<CAAWbhmh5LiE16nLZcjBjTACzSp4vCJsuiQLsHmzFKdMEncHKdg@mail.gmail.com>
<Y+V3p2k6yBUWm9N5@paquier.xyz>
<9f193dd6-e1c5-fb20-ea90-0e6d03760be8@iki.fi>
<Y+Xk8N/atQixeE2/@paquier.xyz>
On 10/02/2023 08:32, Michael Paquier wrote:
> On Fri, Feb 10, 2023 at 02:24:12AM +0200, Heikki Linnakangas wrote:
>>>> How will this evolve when SCRAM-SHA-512 is implemented? Do you
>>>> plan to upgrade the undef-hash in that case to SHA-512?
>>
>> Yes, that's what I had in mind. Or for SCRAM-SHA-512, we could go
>> further and define it as "always use SHA-512", because we wouldn't
>> need to worry about backwards compatibility anymore.
>
> Hmm. There is a risk of breakage here with older versions of libpq
> because we'd still need to support both 256 and 512, no? Or do you
> mean to drop SCRAM-SHA-256 and do a drop-in replacement with
> SCRAM-SHA-512? Doing that in the server may be fine, not in libpq.
> As long as you control that with the channel binding name, there
> should be enough control I guess.
We would still support for SCRAM-SHA-256-PLUS in client and server. But
*if* the server supports and advertises SCRAM-SHA-512-PLUS as a
supported mechanism, and the client supports and selects it, then with
SCRAM-SHA-512-PLUS, we could always use SHA-512 as the hash algorithm
for the channel binding.
Yeah, a MITM could force a downgrade from SCRAM-SHA-512 to
SCRAM-SHA-256, by modifying the list of supported SASL mechanisms that
the server sends. Then again, usually the server would not advertise
both SCRAM-SHA-256 and SCRAM-SHA-512, because pg_role contains only one
password verifier. Unless we change that too. I don't have a solution
for these issues right now, but they are not related to channel binding.
The point is that if we add a new SASL mechanism, like
SCRAM-SHA-512-PLUS, we are free to define how to calculate the
certificate hash with that mechanism however we want, without breaking
backwards compatibility.
> So, using a new channel binding name with
> tls-server-end-point-sha-256 is actually the way to violate the RFC,
> while tls-server-end-point still tries to stick with it?
Correct.
> I am not sure if there's much benefit in a second channel binding,
> enforcing SHA-256 for undefined signatures could just be better, and
> simpler. :)
The benefit is that it's more explicit, which helps to reduce the
confusion. As new signature algorithms are invented in the future, who
knows what OBJ_find_sigid_algs() in different versions of OpenSSL, or
other TLS libraries, will do with them. With a new
"tls-server-end-point-sha-256" channel binding type, it's clear.
> There be a risk of a downgrade attack here, where the client could
> feign the server to do a SHA-256 computation where SHA-512 or higher
> should be used. Or, if the server certificate has a hash function
> but the client feigns in not knowing that, do you mean to go through
> a mock authentication in this case and fail?
Let's always allow tls-server-end-point-sha-256 in the server. The point
of channel binding is to protect the client from a MITM. The client
chooses the channel binding type to use, so a MITM cannot force it to
downgrade.
To be honest, I am not at all worried about losing security by using
SHA-256 instead of SHA-512 or whatever else is in the certificate. If
you don't trust SHA-256, you wouldn't be comfortable using SCRAM-SHA-256
at all.
"tls-server-end-point-sha-256" is simpler than the current rules, so new
client implementations that are not worried about
backwards-compatibility might not bother with the current rules at all,
and only implement "tls-server-end-point-sha-256".
- 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, gunnar.bluth@pro-open.de, pgsql-bugs@lists.postgresql.org
Subject: Re: BUG #17760: SCRAM authentication fails with "modern" (rsassaPss signature) server certificate
In-Reply-To: <687f8e73-e511-6994-c2e2-3cc55633fab6@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