[openssl-project] The problem of (implicit) relinking and changed behaviour

[Andy Polyakov]

> 2. Make TLSv1.2 the absolutely maximum TLS version available for
>    programs linked with libssl 1.1.0.  This is what's done in this PR:
>    https://github.com/openssl/openssl/pull/5945
>    This makes sense insofar that it's safe, it works within the known
>    parameters for the library these programs were built for.

Here is a thing. If we assume that 110/test/sslapitest.c is
*representative* example of an 1.1.0 application, then it's not at all
given that #5945 would actually solve anything. Indeed, observing the
first failing test, recompiled 110/test/sslapitest.c would still fail,
because it makes assumption that session id is available right after
negotiation, something that doesn't hold true for TLS 1.3. This gives
you either a) no 1.1.0 application goes safe, recompiled[!] or not; b)
110/test/sslapitest.c is not representative example. Well, as far as
first failing test goes, I'd say it's b), which means that it should be
adjusted in one way or another or failing check omitted. [It's b),
because it's unnatural to put session id you've just got back to id
cache, the test is ultimately synthetic.] This naturally doesn't answer
all the questions, but it does show that above mentioned premise is
somewhat flawed. I mean "programs were built for [1.1.0]" would still
work if recompiled with #5945.

>    It also makes sense if we view TLSv1.3 as new functionality, and
>    new functionality is usually only available to those who
>    explicitely build their programs for the new library version.
>    TLSv1.3 is unusual in this sense because it's at least it great
>    part "under the hood", just no 100% transparently so.

In such case it should rather be #ifdef OPENSSL_ENABLE_TLS1_3 instead of
#ifndef OPENSSL_DISABLE_TLS1_3. And we don't want that.

To summarize, failing tests in 110 should be revisited to see if they
are actually representative, before one can consider as drastic measures
as #5945.