Re: Post-CVE Wishlist

On 23/11/2021 23:44, Robert Haas wrote:
> 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 =

Aside from security, one small benefit of skipping the Starttls-style
negotiation is that you avoid one round-trip to the server.

>> 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, iswh
> 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.
One intriguing option is to allow starting the TLS handshake without the
SSLRequest packet. On the same port. A TLS handshake and PostgreSQL
SSLRequest/StartupMessage/CancelRequest can be distinguished by looking
at the first few bytes. The server can peek at them, and if it looks
like a TLS handshake, start TLS (or fail if it's not supported),
otherwise proceed with the libpq protocol.

This would make the transition smooth: we can add server support for
this now, with an option in libpq to start using it. After some years,
we can make it the default in libpq, but still fall back to the old
method if it fails. After a long enough transition period, we can drop
the old mechanism.

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?

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

Huh, that's surprising, I though the trend is towards implicit TLS. As
another data point, RFC 8314 recommends implicit TLS for POP, IMAP and SMTP.

- Heikki