Re: Post-CVE Wishlist

From: Jacob Champion <pchampion(at)vmware(dot)com>
To: "hlinnaka(at)iki(dot)fi" <hlinnaka(at)iki(dot)fi>, "robertmhaas(at)gmail(dot)com" <robertmhaas(at)gmail(dot)com>
Cc: "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>, "tgl(at)sss(dot)pgh(dot)pa(dot)us" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Subject: Re: Post-CVE Wishlist
Date: 2021-11-24 18:29:44
Message-ID: 8f267b13469249d30a219292fab35ad13cbedd8e.camel@vmware.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Christofides 2021-11-24 18:35:45 Re: BUFFERS enabled by default in EXPLAIN (ANALYZE)
Previous Message Robert Haas 2021-11-24 18:16:37 Re: pgsql: xlog.c: Remove global variables ReadRecPtr and EndRecPtr.