Re: BUG #17760: SCRAM authentication fails with "modern" (rsassaPss signature) server certificate

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