On Thu, Jun 25, 2020 at 12:30:03AM +0200, Daniel Gustafsson wrote: > I don't think anyone argues against safe defaults for communication between > upgraded clients and upgraded servers. That being said; out of the box, an > upgraded client *will* use TLSv1.2 when connecting to a upgraded server due to > the server defaults requirements (assuming the server hasn't been reconfigured > with a lower TLS version, but since we're talking defaults we have to assume > that).
My take here is to let things as they are for libpq. pg_dump is a very good argument, because we allow backward compatibility with a newer version of the tool, not upward compatibility. > The problem comes when an updated client needs to talk to an old server which > hasn't been upgraded and which use an older OpenSSL version. If we set > TLSv1.2 > as the minimum client version, the user will have to amend a connection string > which used to work when talking to a server which hasn't changed. If we don't > raise the default, a user to wants nothing lower than TLSv1.2 will have to > amend the connection string. 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. > As mentioned elsewhere in the thread, maybe this is also something which can > be > done more easily if we improve the error reporting? Right now it's fairly > cryptic IMO. This part may be tricky to get right I think, because the error comes directly from OpenSSL when negotiating the protocol used between the client and the server, like "no protocols available" or such. -- Michael
signature.asc
Description: PGP signature
