> On 26 Jun 2020, at 22:22, Tom Lane <t...@sss.pgh.pa.us> wrote: > > I wrote: >> Anybdy have a better idea? Is there a reasonably direct way to ask >> OpenSSL what its min and max versions are? > > After some digging, there apparently is not.
AFAIK everyone either #ifdef around the TLS1_x_VERSION macros or the OpenSSL versioning and use hardcoded knowledge based on that. The latter is fairly shaky since configure options can disable protocols. At least in past versions, the validation for protocol range in OpenSSL ssl_lib was doing pretty much that too. > So I propose the attached. SSL_R_UNKNOWN_PROTOCOL seem to covers cases when someone manages to perform something which OpenSSL believes is a broken SSLv2 connection, but their own client-level code use it to refer to SSL as well as TLS. Maybe it's worth adding as a belts and suspenders type thing? I've only had a chance to read the patches, but they read pretty much just like I had in mind that we could do this. +1 on both patches from an eye-ball POV. Is this targeting v13 or v14? In case of the former, the release notes entry for raising the default minimum version should perhaps be tweaked as it now just refers to the GUC which is a tad misleading. > The hack in openssl.h to guess the > min/max supported versions is certainly nothing but a hack; > but I see no way to do better. If anything it might useful to document in the comment that we're only concerned with TLS versions, SSL2/3 are disabled in the library initialization. cheers ./daniel