From: | Heikki Linnakangas <hlinnaka(at)iki(dot)fi> |
---|---|
To: | Jacob Champion <jchampion(at)timescale(dot)com>, Michael Paquier <michael(at)paquier(dot)xyz> |
Cc: | gunnar(dot)bluth(at)pro-open(dot)de, pgsql-bugs(at)lists(dot)postgresql(dot)org |
Subject: | Re: BUG #17760: SCRAM authentication fails with "modern" (rsassaPss signature) server certificate |
Date: | 2023-02-11 10:58:02 |
Message-ID: | b6e6d13f-b912-4c6e-c12a-2c7934bdc830@iki.fi |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
On 11/02/2023 02:13, Jacob Champion wrote:
> On Thu, Feb 9, 2023 at 2:46 PM Michael Paquier <michael(at)paquier(dot)xyz> wrote:
>> 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.
>
> My take on this bug is that Gunnar doesn't need to solve the general
> "undef" case. They've got a certificate that's supposed to be using
> SHA512.
>
> It looks like OpenSSL 1.1.1 gives us a better API for grabbing that;
> see attached draft (not mesonified, needs independent verification),
> which fixes Heikki's certificate case at least. It's unfortunate that
> it doesn't reach back to 1.0.2, or to LibreSSL, but that doesn't
> appear to be a problem for Gunnar's situation, and you'd mentioned
> wanting to drop 1.0.2 support in HEAD soon anyway.
A-ha! I browsed around OpenSSL APIs and the source code, but missed
X509_get_signature_info(). Good find!
X509_get_signature_info() calls X509_check_purpose(), which calls
internal function ossl_x509v3_cache_extensions(), which extracts and
caches quite a lot of information from the certificate. It calculates
and caches its SHA1 hash, for example. That seems acceptable, the
overhead is negligible and I don't see any scenario where
X509_get_signature_nid() would succeed but X509_get_signature_info()
would fail.
+1 on your patch. I think the only thing it's missing is changes in
meson.build and Solution.pm to match the configure.ac changes.
> Maybe someone really wants to use EdDSA certs, which aren't handled by
> that API. But this stopgap would buy us some time for the
> cryptographers to settle on things -- or at least to ask them? And if
> people want new crypto they're going to need to upgrade eventually.
> (Maybe by that point we'll know that X509_digest_sig() is in fact
> correct for bindings.)
Agreed, if we have an easy solution for RSA-PSS, that's good enough for now.
> <strong opinions>
> - Our current departures from the spec (e.g. no tls-unique) mean that
> we already can't interoperate with standard SASL libraries. I've been
> trying to realign them, slowly.
> - Coming up with our own binding type takes time and resources away
> from other things this thread highlighted (the ability to force the
> use of a binding at the server side. better behavior when we can't
> actually compute a binding value. tls-exporter support...).
> - Worst case, using SHA256 for a future certificate type might be
> *catastrophically* wrong, but no one's going to warn us, and it's not
> going to be obvious to the DBA or their users that our nonstandard
> binding is in effect.
> - Best case, we choose exactly right, but if/when tls-server-end-point
> gets updated for EdDSA, the world will move on and we'll still have to
> support that vestigial binding type for the next X years.
> </strong opinions>
Fair points.
- Heikki
From | Date | Subject | |
---|---|---|---|
Next Message | Dmitry Dolgov | 2023-02-11 19:00:37 | Re: BUG #17774: Assert triggered on brin_minmax_multi.c |
Previous Message | Andres Freund | 2023-02-11 01:51:12 | Re: BUG #17777: An assert failed in nodeWindowAgg.c |