Re: Post-CVE Wishlist - Mailing list pgsql-hackers

From Jacob Champion
Subject Re: Post-CVE Wishlist
Date
Msg-id 8f267b13469249d30a219292fab35ad13cbedd8e.camel@vmware.com
Whole thread Raw
In response to Re: Post-CVE Wishlist  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: Post-CVE Wishlist
Re: Post-CVE Wishlist
List pgsql-hackers
On Wed, 2021-11-24 at 09:40 -0500, Robert Haas wrote:
> I am not really persuaded by Jacob's argument that, had this only
> worked the other way from the start, this bug wouldn't have occurred.
> That's just a tautology, because we can only have bugs in the code we
> write, not the code we didn't write. So perhaps we would have just had
> some other bug, which might have been more or less serious than the
> one we actually had. It's hard to say, really, because the situation
> is hypothetical.

I'm not trying to convince you that there wouldn't have been bugs.
There will always be bugs.

What I'm trying to convince you of is that this pattern of beginning a
TLS conversation is known to be particularly error-prone, across
multiple protocols and implementations. I think this is supported by
the fact that at least three independent client libraries made changes
in response to this Postgres CVE, a decade after the first writeup of
this exact vulnerability.

- https://github.com/postgres/postgres/commit/160c0258802
- https://github.com/pgbouncer/pgbouncer/commit/e4453c9151a
- https://github.com/yandex/odyssey/commit/4e00bf797a

I don't buy the idea that, because we have fixed that particular
vulnerability, we've rendered this entire class of bugs "hypothetical".
There will be more code and more clients. There will always be bugs.
I'd rather the bugs that people write be in places that are less
security-critical.

> This argument doesn't answer the question of whether speaking pure SSL
> on a separate port is better or worse than having a single port that
> does either. If I had to guess, the latter is more convenient for
> users but less convenient to code. I don't even see a compelling
> reason why we can't support multiple models here, supposing someone is
> willing to do the work and fix the bugs that result.

I only have experience in the area of HTTP(S), which supports three
models of plaintext-only, plaintext-upgrade-to-TLS (which is rare in
practice), and implicit-TLS. I'm not aware of mainstream efforts to mix
plaintext and implicit-TLS traffic on the same HTTP port -- but there
are projects that fill that niche [1] -- so I don't know what security
issues might arise from that approach.

--Jacob

[1] https://github.com/mscdex/httpolyglot

pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: pgsql: xlog.c: Remove global variables ReadRecPtr and EndRecPtr.
Next
From: Michael Christofides
Date:
Subject: Re: BUFFERS enabled by default in EXPLAIN (ANALYZE)