Re: Post-CVE Wishlist

On Tue, Nov 23, 2021 at 5:41 PM Heikki Linnakangas <hlinnaka(at)iki(dot)fi> wrote:
> All that said, I'm not sure how serious I am about this. I think it
> would work, and it wouldn't even be very complicated, but it feels
> hacky, and that's not a good thing with anything security related. And
> the starttls-style negotiation isn't that bad, really. I'm inclined to
> do nothing I guess. Thoughts?

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.

But on reflection, one thing that isn't very nice about the current
approach is that it won't work with anything that doesn't support the
PostgreSQL wire protocol specifically. Imagine that you have a driver
for PostgreSQL that for some reason does not support SSL, but you want
to use SSL to talk to the server. You cannot stick a generic proxy
that speaks plaintext on one side and SSL on the other side between
that driver and the server and have it work. You will need something
that knows how to proxy the PostgreSQL protocol specifically, and that
will probably end up being higher-overhead than a generic proxy. There
are all sorts of other variants of this scenario, and one of them is
probably the motivation behind the request for proxy protocol support.
I don't use these kinds of software myself, but I think a lot of
people do, and it wouldn't be a bad thing if we could be
"plug-compatible" with things that people on the Internet want to do,
without needing a PostgreSQL-specific adapter. SSL is certainly one of
those things.

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.

--
Robert Haas
EDB: http://www.enterprisedb.com