On Thu, Mar 20, 2025 at 6:11 AM Jelte Fennema-Nio <postgres@jeltef.nl> wrote:
> I'm not saying there's no attack possible here (although I cannot
> think of one), but we allow configuring every other SSL option using
> an env var^1. So if there is an attack possible, why would that only
> apply to being able to control the sslkeylogfile as opposed to e.g.
> sslmode or sslrootcert.
(First off: I was specifically referring to the "if X and Y, then it's
game over, so might as well Z too" line of argument. I think that kind
of reasoning causes problems in OSS security.)
I don't think the argument against an envvar is being made from the
point of view of consistency. That's not very helpful in security
contexts, where we'd rather be inconsistently good/better than
consistently bad. (And existing clients that allow an adversary to
control the PGSSLROOTCERT environment variable are broken, and have
been since, what, 2009? I'm not going to spend energy on that.)
The argument is about net-new behavior: is it okay for a new
environment variable to silently log key material for all our
connections to an arbitrary location on disk? I feel less strongly
about it than Tom does, looks like, but the additional risk is
definitely not zero. Maybe we could declare a prefix of environment
variables to be security-critical or something, to help that concern
in the future.
OpenSSL 3.5 will add native support for the SSLKEYLOGFILE envvar, but
I think they've locked it behind both a build-time option and a
default-off configuration setting. And there are moving discussions
[1] on whether they might provide a setting to centrally disable the
logging callback used in this patch, too. I think Tom's concern has
merit, and I think we should move cautiously here.
Thanks,
--Jacob
[1] https://github.com/openssl/openssl/issues/26282
