[openssl-project] The problem of (implicit) relinking and changed behaviour
levitte at openssl.org
Sat Apr 14 20:18:15 UTC 2018
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> 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> 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> 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> 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> 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
Richard Levitte levitte at openssl.org
OpenSSL Project http://www.openssl.org/~levitte/
More information about the openssl-project