Re: [PATCH] Add `verify-system` sslmode to use system CA pool for server cert

From: Jacob Champion <jchampion(at)timescale(dot)com>
To: Daniel Gustafsson <daniel(at)yesql(dot)se>
Cc: "Gregory Stark (as CFM)" <stark(dot)cfm(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, Magnus Hagander <magnus(at)hagander(dot)net>, Michael Paquier <michael(at)paquier(dot)xyz>, thomas(at)habets(dot)se, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Bruce Momjian <bruce(at)momjian(dot)us>, Andrew Dunstan <andrew(at)dunslane(dot)net>, Jelte Fennema <postgres(at)jeltef(dot)nl>
Subject: Re: [PATCH] Add `verify-system` sslmode to use system CA pool for server cert
Date: 2023-03-31 17:59:44
Message-ID: 8819ba23-3111-777b-0479-50c18cbb8a5f@timescale.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 3/31/23 02:14, Daniel Gustafsson wrote:
>> On 14 Mar 2023, at 20:20, Jacob Champion <jchampion(at)timescale(dot)com> wrote:
>
>> Rebased over yesterday's Meson changes in v8.
>
> I had a look at this and agree that it's something we should do.

Great, thanks for the review!

> + # Let tests differentiate between vanilla OpenSSL and LibreSSL.
> + AC_CHECK_DECLS([LIBRESSL_VERSION_NUMBER], [], [], [#include <openssl/opensslv.h>])
> We have a check for SSL_CTX_set_cert_cb which is specifically done since it's
> not present in Libressl. Rather than spending more cycles in autoconf/meson,
> couldn't we use HAVE_SSL_CTX_SET_CERT_CB for this test? (Longer term, maybe we
> should make the checks properly distinguish between OpenSSL and LibreSSL as
> they are diverging, but thats not for this patch to tackle.)

I can make that change; note that it'll also skip some of the new tests
with OpenSSL 1.0.1, where there's no SSL_CTX_set_cert_cb. If that's
acceptable, it should be an easy switch.

> I can agree with the comment that this seems brittle. How about moving the installation of openssl to after the brew cleanup stage to avoid the need for this? While that may leave more in the cache, it seems more palatable. Something like this essentially:
>
> brew install <everything but openssl>
> brew cleanup -s
> # Comment about why OpenSSL is kept separate
> brew install openssl(at)3

That looks much better to me, but it didn't work when I tried it. One or
more of the packages above it (and/or the previous cache?) has already
installed OpenSSL as one of its dependencies, so the last `brew install`
becomes a no-op. I tried an `install --force` as well, but that didn't
seem to do anything differently. :/

> + libpq_append_conn_error(conn, "weak sslmode \"%s\" may not be used with sslrootcert=system",
> + conn->sslmode);
> I think we should help the user by indicating which sslmode we allow in this
> message.

Added in v9.

> +
> + /*
> + * sslmode is not specified. Let it be filled in with the compiled
> + * default for now, but if sslrootcert=system, we'll override the
> + * default later before returning.
> + */
> + sslmode_default = option;
> As a not to self and other reviewers, "git am" misplaced this when applying the
> patch such that the result was syntactically correct but semantically wrong,
> causing very weird test errors.

Lovely... I've formatted v9 with a longer patch context.

> + sslmode_default->val = strdup("verify-full");
> This needs to be checked for OOM error.

Whoops, should be fixed now.

> - if (fnbuf[0] != '\0' &&
> - stat(fnbuf, &buf) == 0)
> + if (strcmp(fnbuf, "system") == 0)
> I'm not a fan of magic values, but sadly I don't have a better idea for this.
> We should however document that the keyword takes precedence over a file with
> the same name (even though the collision is unlikely).

Added a note to the docs.

> + if (SSL_CTX_set_default_verify_paths(SSL_context) != 1)
> OpenSSL documents this as "A missing default location is still treated as a
> success.", is that something we need to document or in any way deal with?
> (Skimming the OpenSSL code I'm not sure it's actually correct in v3+, but I
> might very well have missed something.)

I think it's still true in v3+, because that sounds exactly like the
brew issue we're working around in Cirrus. I'm not sure if there's much
for us to do in that case, short of reimplementing the OpenSSL defaults
logic and checking it ourselves. (And even that would look different
between OpenSSL and LibreSSL...)

Is there something we could document that's more helpful than "make sure
your installation isn't broken"?

--Jacob

Attachment Content-Type Size
since-v8.diff.txt text/plain 2.3 KB
v9-0001-libpq-add-sslrootcert-system-to-use-default-CAs.patch text/x-patch 26.0 KB
v9-0002-libpq-force-sslmode-verify-full-for-system-CAs.patch text/x-patch 10.8 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Imseih (AWS), Sami 2023-03-31 18:06:46 Re: [BUG] pg_stat_statements and extended query protocol
Previous Message Dmitry Dolgov 2023-03-31 17:39:27 Re: [RFC] Add jit deform_counter