On 23/11/2021 23:44, Robert Haas wrote:
On Tue, Nov 23, 2021 at 2:18 PM Tom Lane <t...@sss.pgh.pa.us> wrote:
Jacob Champion <pchamp...@vmware.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
