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

[Richard Levitte]

In message <352EBAA2-B2D4-4A2E-ADC4-1033A1735ADC at dukhovni.org> on Sat, 14 Apr 2018 16:01:42 -0400, Viktor Dukhovni <openssl-users at dukhovni.org> said:

openssl-users> > 2. Make TLSv1.2 the absolutely maximum TLS version available for
openssl-users> >   programs linked with libssl 1.1.0.  This is what's done in this PR:
openssl-users> >   https://github.com/openssl/openssl/pull/5945
openssl-users> >   This makes sense insofar that it's safe, it works within the known
openssl-users> >   parameters for the library these programs were built for.
openssl-users> >   It also makes sense if we view TLSv1.3 as new functionality, and
openssl-users> >   new functionality is usually only available to those who
openssl-users> >   explicitely build their programs for the new library version.
openssl-users> >   TLSv1.3 is unusual in this sense because it's at least it great
openssl-users> >   part "under the hood", just no 100% transparently so.
openssl-users> 
openssl-users> This should NOT be necessary.  What it is about enabling TLS 1.3
openssl-users> that breaks existing code?  Let's fix that.

I'm not savvy enough to answer that properly.  I'm mostly observing
from the exterior.

openssl-users> > 3. ....  I dunno, please share ideas if you have them.
openssl-users> 
openssl-users> We need to make sure that the introduction of TLS 1.3 is transparent,
openssl-users> aside from occasionally leading to a connection that uses TLS 1.3.
openssl-users> 
openssl-users> If all that's failing is our test-suite, which is too sensitive to the
openssl-users> underlying implementation details, that's fine, not all the tests are 
openssl-users> designed to run cross-library.
openssl-users> 
openssl-users> Will real applications run into any meaningful problems?

This is an argument that I find *terribly* frustrating.  Are you
suggesting that we have no test that tries to do what can be expect
from a "real" application?  What do you expect a "real" application to
limit itself to?  Do you expect a "real" application to always set a
maximum TLS version?  Do you expect a "real" application to expect
failure because it hasn't?  Was any of the limitations you might think
of advertised?  In the 1.1.0 manual pages?  Elsewhere?

Also, I imagine that test_ssl_old, test_ssl_new and test_sslapi are
three tests that do try to mimic "real world" use of libssl.

openssl-users> While can artificially limit the max protocol in applications compiled
openssl-users> for 1.1.0, I don't think that's a compelling design choice.  We have
openssl-users> support in 1.1.0 for min/max protocol, applications can use those
openssl-users> controls explicitly.

Yes, they can, but they won't necessarely.  Just as an example, our
1.1.0 test programs didn't before I stoopidly made them do so (I'm
reverting that with https://github.com/openssl/openssl/pull/5947,
because it was an enormously stoopid move that only showed that an
upgrade to 1.1.1 *required* at least the addition of such controls)

openssl-users> In any case in order of preference, I'd like to see:
openssl-users> 
openssl-users>   1. Fix any issues so that it is safe to upgrade.
openssl-users>   2. Make the library version 1.2
openssl-users>   3. Hack the API to cap the protocol version based on compile-time
openssl-users>      maximum.
openssl-users> 
openssl-users> -- 
openssl-users> -- 
openssl-users> 	Viktor.

-- 
Richard Levitte         levitte at openssl.org
OpenSSL Project         http://www.openssl.org/~levitte/