Re: Post-CVE Wishlist

Поиск
Список
Период
Сортировка
От Jacob Champion
Тема Re: Post-CVE Wishlist
Дата
Msg-id 8f267b13469249d30a219292fab35ad13cbedd8e.camel@vmware.com
обсуждение исходный текст
Ответ на Re: Post-CVE Wishlist  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: Post-CVE Wishlist  (Robert Haas <robertmhaas@gmail.com>)
Re: Post-CVE Wishlist  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: pgsql: xlog.c: Remove global variables ReadRecPtr and EndRecPtr.
Следующее
От: Michael Christofides
Дата:
Сообщение: Re: BUFFERS enabled by default in EXPLAIN (ANALYZE)