On Wed, Jun 24, 2020 at 9:50 PM Michael Paquier <mich...@paquier.xyz> wrote: > Yeah, and I would not be surprised to see cases where people complain > to us about that when attempting to reach one of their old boxes, > breaking some stuff they have been relying on for years by forcing the > addition of a tls_min_server_protocol in the connection string. It is > a more important step that we enforce TLSv1.2 on the server side > actually, and libpq just follows up automatically with that.
I wonder how much of a problem this really is. A few quick Google searches suggests that support for TLSv1.2 was added to OpenSSL in v1.0.1, which was released in March 2012. If packagers adopted that version for the following PostgreSQL release, they would have had TLSv1.2 support from PostgreSQL 9.2 onward. Some people may have taken longer to adopt it, but even if they waited a year or two, all versions that they built with older OpenSSL versions would now be out of support. It doesn't seem that likely that there are going to be that many people using pg_dump to upgrade directly from PostgreSQL 9.2 -- or even 9.4 -- to PostgreSQL 13. Skipping six or eight major versions in a single upgrade is a little unusual, in my experience. And even if someone does want to do that, we haven't broken it; it'll still work fine if they are connecting through a UNIX socket, and if not, they can disable SSL or just specify that they're OK with an older protocol version. That doesn't seem like a big deal, especially if we can adopt Tom's suggestion of giving them a warning about what went wrong. Let's also consider the other side of this argument, which is that a decent number of PostgreSQL users are operating in environments where they are required for regulatory compliance to prohibit the use of TLSv1.0 and TLSv1.1. Those people will be happy if that is the default on both the client and the server side by default. They will probably be somewhat happy anyway, because now we have an option for it, which we didn't before. But they'll be more happy if it's the default. Now, we can't please everybody here. Is it more important to please people who would like insecure TLS versions disabled by default, or to please people who want to use insecure TLS versions to back up old servers? Seems debatable. Based on my own experience, I'd guess there are more users who want to avoid insecure TLS versions than there are users who want to use them to back up very old servers, so I'd tentatively favor changing the default. However, I don't know whether my experiences are representative. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
