Re: Post-CVE Wishlist
От | Robert Haas |
---|---|
Тема | Re: Post-CVE Wishlist |
Дата | |
Msg-id | CA+TgmobMDiu+VeBfHurqJeo-PgW=82_5SrbjdgDStch_AYpusg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Post-CVE Wishlist (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Post-CVE Wishlist
(Tom Lane <tgl@sss.pgh.pa.us>)
Re: Post-CVE Wishlist (Heikki Linnakangas <hlinnaka@iki.fi>) |
Список | pgsql-hackers |
On Tue, Nov 23, 2021 at 2:18 PM Tom Lane <tgl@sss.pgh.pa.us> wrote: > Jacob Champion <pchampion@vmware.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
В списке pgsql-hackers по дате отправления: