From: Michael Paquier <michael@paquier.xyz>
To: Heikki Linnakangas <hlinnaka@iki.fi>
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 15:32:16 +0900
Message-ID: <Y+Xk8N/atQixeE2/@paquier.xyz> (raw)
In-Reply-To: <9f193dd6-e1c5-fb20-ea90-0e6d03760be8@iki.fi>
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>
On Fri, Feb 10, 2023 at 02:24:12AM +0200, Heikki Linnakangas wrote:
> Note that the discussion in that thread is in a slightly different context.
> They are not talking about channel binding, but something else
> (https://github.com/openssl/openssl/issues/15477#issuecomment-852928702).
> The problem is similar: what hash algorithm to use if it's not well defined.
> But there's no guarantee that the rules they come up with will be the same
> as the rules for tls-server-end-point. So I'm not very comfortable relying
> on X509_digest_sig() to do the right thing for us in the future, even if it
> does today.
Okay. Yes, it does not seem like a good idea in the long run to avoid
that.
>>> 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.
> Let's define a new channel binding type: tls-server-end-point-sha-256. with
> "tls-server-end-point-sha-256", the SHA-256 hash of the certificate is used,
> regardless of what algorithm is in the certificate's signature.
>
> 1. When the client sees a "normal" server certificate that uses SHA-256,
> SHA-512, or something else that it recognizes and handles fine today, it
> does the same thing as it does today. It sends "tls-server-end-point" as the
> the cb-name, and calculates the hash using the certificate's hash algorithm.
>
> 2. When the client sees a certificate with RSA-PSS, ED25519, ED448, or any
> other signature method that it doesn't recognize, it selects the
> tls-server-end-point-sha-256 channel binding type. It sends
> "tls-server-end-point-sha-256" as the cb-name, and calculates the SHA-256
> hash of the certificate.
>
> 3. The server follows the current rules, or uses SHA-256, depending on
> whether the client sent "tls-server-end-point" or
> "tls-server-end-point-sha-256" in the cb-name.
>
> These rules ensure that with certificates that work today, nothing changes.
> Rule 1 ensures that you can connect with a new client to an old server, and
> it still works. And rule 3. ensures that you can still connect to a new
> server with an old client.
>
> At the same time, we are using a new channel binding type to make it clear
> when we are deviating from the standard rules of "tls-server-end-point".
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? 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. :)
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?
> If you have an RSA-PSS certificate, you need to upgrade the client and the
> server, or you get an error when you try to connect. (Unless you set
> channel_binding=disable). But after upgrading, it will work.
Indeed.
--
Michael
Attachments:
signature.asc (application/pgp-signature, 832B) download
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: michael@paquier.xyz, hlinnaka@iki.fi, 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: <Y+Xk8N/atQixeE2/@paquier.xyz>
* 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