> On 26 Jun 2020, at 22:22, Tom Lane <tgl@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
