Re: Post-CVE Wishlist

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Post-CVE Wishlist
Дата
Msg-id 182060.1637780630@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Post-CVE Wishlist  (Jacob Champion <pchampion@vmware.com>)
Ответы Re: Post-CVE Wishlist  (Jacob Champion <pchampion@vmware.com>)
Список pgsql-hackers
Jacob Champion <pchampion@vmware.com> writes:
> 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.

Well, it's not clear that they didn't just copy libpq's buggy logic,
so I'm not sure how "independent" these bugs are.  I actually took
considerable comfort from the number of clients that *weren't*
vulnerable.

> 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.

Unless we actively remove the existing way of starting SSL encryption
--- and GSS encryption, and anything else somebody proposes in future ---
we are not going to be able to design out this class of bugs.  Maybe
we could start the process now in the hopes of making such a breaking
change ten years down the road; but whether anyone will remember to
pull the trigger then is doubtful, and even if we do remember, you can
be dead certain it will still break some people's clients.  So I don't
put much stock in the argument that this will make things more secure.
(Ten years from now, SSL may be dead and replaced by something more
secure against quantum computers.)

The suggestion that we could remove one network roundtrip is worth
something.  And perhaps the argument about improving compatibility
with tools that know SSL but not the PG wire protocol (although
that one seems pretty unbacked by concrete facts).  Whether these
things make it worth the effort is dubious in my mind, but others
may evaluate that differently.  Note, however, that neither argument
impels us to break compatibility with existing clients.  That's a
far heavier price to pay, and basically I don't believe that we
are willing to pay it.

            regards, tom lane



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: Post-CVE Wishlist
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Should rename "startup process" to something else?