From: Heikki Linnakangas <hlinnaka@iki.fi>
To: Michael Paquier <michael@paquier.xyz>
To: 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 02:24:12 +0200
Message-ID: <9f193dd6-e1c5-fb20-ea90-0e6d03760be8@iki.fi> (raw)
In-Reply-To: <Y+V3p2k6yBUWm9N5@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>
On 10/02/2023 00:45, Michael Paquier wrote:
> On Thu, Feb 09, 2023 at 02:22:28PM -0800, Jacob Champion wrote:
>> +1. I'm still coming up to speed on RSA-PSS and the conversation at
>>
>> https://github.com/openssl/openssl/issues/15477
>>
>> but it makes me really uncomfortable to fail open rather than shut in
>> this case, as part of a backport.
>
> I could get that some users would want to be able to use such certs,
> though. At least we have one such user as of this thread.
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.
>>>> 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.
>>
>> 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.
>> Knee-jerk reaction: this departure feels unnecessary since Gunnar's
>> certificate does in fact contain a hash algorithm...
>
> What do you mean by Gunnar here?
Gunnar reported the bug, he's cc'd in this thread.
Ok, let me refine my earlier idea to make this more concrete:
> 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.
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".
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.
- 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: <9f193dd6-e1c5-fb20-ea90-0e6d03760be8@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