Hi, On Thu, Dec 6, 2018 at 3:29 AM Steffan Karger <steffan.kar...@fox-it.com> wrote: > > On 05-12-18 15:09, Arne Schwabe wrote: > > Am 05.12.18 um 11:51 schrieb Steffan Karger: > >> 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" > > Do you mean "add a warning message *in addition to* the patch > workarounds", or "add a warning message "instead of* the patch workarounds"? > > I'm definitely in favour of adding the warning, but would need to think > a bit more about whether adding the workarounds will give net-positive > results.
I was of the view that we should support upgrade to OpenSSL 1.1.1 without recompiling, but on closer encounters with 1.1.1, I have a change of mind. In our case, the only real problem is: if OpenSSL 1.1.1 is in use at run time, external certificate support is broken and needs fixing. But does that need this patch? Two cases to consider: (i) compiled against 1.1.0 but the dynamic linker loads 1.1.1 (ii) compiled and run against 1.1.1 For fixing "management-external-cert", case (i) may need this but case (ii) doesn't. That said, the ABI compat between 1.1.0 and 1.1.1 that OpenSSL claims has caveats, so we need not promote use case (i). Just warn this may not work and let things fail if and when it fails. Even in case of (ii) my view is that we should just let external signing fail if the management client is not capable of handling the signature request (cases where the data is either prepadded or requires PSS padding). Such an approach still requires some changes to the code to support non PKCS1 padding but that's the topic of a different set of patches. Selva Selva _______________________________________________ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
