Re: Post-CVE Wishlist

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Jacob Champion <pchampion(at)vmware(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Post-CVE Wishlist
Date: 2021-11-23 21:44:43
Message-ID: CA+TgmobMDiu+VeBfHurqJeo-PgW=82_5SrbjdgDStch_AYpusg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Nov 23, 2021 at 2:18 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Jacob Champion <pchampion(at)vmware(dot)com> writes:
> > = Implicit TLS =
>
> I think this idea is a nonstarter. It breaks backwards compatibility
> at the protocol level in order to fix entirely-hypothetical bugs.
> Nobody is going to like that tradeoff. Moreover, how shall the
> server know whether an incoming connection is expected to use TLS
> or not, if no prior communication is allowed? "TLS is the only
> supported case" is even more of a nonstarter than a protocol change.

I am not persuaded by this argument. Suppose we added a server option
like ssl_port which causes us to listen on an additional port and, on
that port, everything, from the first byte on this connection, is
encrypted using SSL. Then we have to also add a matching libpq option
which the client must set to tell the server that this is the
expectation. For people using URL connection strings, that might be as
simple as specifying postgresqls://whatever rather than
postgresql://whatever. With such a design, the feature is entirely
ignorable for those who don't wish to use it, but anyone who wants it
can get it relatively easily. I don't know how we'd ever deprecate the
current system, but we don't necessarily need to do so. LDAP allows
either kind of scheme -- you can either connect to a regular LDAP
port, usually port 389, and negotiate security, or you can connect to
a different port, usually 636, and use SSL from the start. I don't see
why that couldn't be a model for us, and I suspect that it would get
decent uptake.

Now that being said, https://www.openldap.org/faq/data/cache/605.html
claims that ldaps (encrpyt from the first byte) is deprecated in favor
of STARTTLS (encrypt by negotiation). It's interesting that Jacob is
proposing to introduce as a new and better option the thing they've
decided they don't like. I guess my question is - is either one truly
better, or is this just a vi vs. emacs type debate where different
people have different preferences? I'm really not sure.

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2021-11-23 22:02:12 Re: Post-CVE Wishlist
Previous Message Tom Lane 2021-11-23 21:43:25 Re: pg_upgrade parallelism