Am 05.12.18 um 11:51 schrieb Steffan Karger: > Hi, > > On Wed, 31 Oct 2018 at 17:53, Arne Schwabe <a...@rfc2549.org> wrote: >> Before OpenSSL 1.1.1 there could be no mismatch between >> compiled and actual OpenSSL version. With OpenSSL 1.1.1 we need >> runtime detection to detect the actual best TLS version supported. >> >> Allowing this runtime detection also allows removing some of the >> TLS 1.3/OpenSSL 1.1.1 #ifdefs >> >> Without this patch tls-min-version 1.3 or-highest will actually >> downgrade to TLS 1.3 in the "compiled with 1.1.0 and linked against >> 1.1.1" scenario. > > "Downgrade to TLS 1.2", I guess? > > But more fundamental: do want to support runtime-upgrading the TLS > library? Are we sure that this is the only place where this will > create unexpected behaviour? Does it even make sense to upgrade a > dependency to a version that contains all sorts of API/ABI changes and > then expect that you do not have to recompile? Honest questions; I > don't understand why one would want or do this.
I think on some installation, especially when the user compiled OpenVPN him/herself, we just need to live with the fact that the OpenSSL library got upgraded from OpenSSL 1.1.0 to OpenSSL 1.1.1. But one art of decting the newer library here is that we can bail out on some of the corner cases instead of continuing, like refusing external auth if the OpenSSL libary is too new. I still think is an unsupported scenario and we might add an warning message aka like "Detected OpenSSL 1.1.1 but compiled against OpenSSL 1.1.0, recompile to use all OpenSSL 1.1.1 features" Arne
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
