On Tue, Mar 15, 2022 at 12:38 AM Dimitri Papadopoulos <dimitri.papadopou...@cea.fr> wrote: > > Hi, > > It definitely looks like an Ubuntu bug. I can reproduce this issue when > building against the OpenSSL library that ships with Ubuntu 20.04: > > $ ./configure \ > --prefix=/my/path/openconnect \ > --with-vpnc-script=/my/src/vpnc-scripts/vpnc-script \ > --with-openssl > $ > $ make check > [...] > FAIL: bad_dtls_test > > <snip> > > This failure disappears after building against a vanilla OpenSSL 1.1.1f: > > $ ./configure \ > --prefix=/my/path/openconnect \ > --with-vpnc-script=/my/src/vpnc-scripts/vpnc-script \ > --with-openssl=/my/src/openssl-1.1.1f > $ > $ make check > [...] > PASS: bad_dtls_test
Great find, Dimitri! Thank you. Per https://packages.ubuntu.com/focal-updates/libssl-dev, this package seems to come straight from Debian with no Ubuntu modifications. A glance at the debian/patches/ directory from http://archive.ubuntu.com/ubuntu/pool/main/o/openssl/openssl_1.1.1f-1ubuntu2.11.debian.tar.xz suggests that there are a pretty stupendously large number of patches applied against the upstream OpenSSL 1.1.1f. ☹ This patch suggests that the "OpenSSL security level" could be the culprit: if the "OpenSSL security level is set to >=2, then vanilla OpenSSL 1.1.1f will allow old/bad/Cisco DTLS, but Debian/Ubuntu OpenSSL 1.1.1f will *not* allow it: tls1.2-min-seclevel2.patch-Description: TLS versions below 1.2 are not permitted as security level 2. tls1.2-min-seclevel2.patch- tls1.2-min-seclevel2.patch-Index: openssl-1.1.1d/ssl/ssl_cert.c tls1.2-min-seclevel2.patch-=================================================================== tls1.2-min-seclevel2.patch---- openssl-1.1.1d.orig/ssl/ssl_cert.c tls1.2-min-seclevel2.patch-+++ openssl-1.1.1d/ssl/ssl_cert.c tls1.2-min-seclevel2.patch-@@ -956,18 +956,12 @@ static int ssl_security_default_callback tls1.2-min-seclevel2.patch- } tls1.2-min-seclevel2.patch- case SSL_SECOP_VERSION: tls1.2-min-seclevel2.patch: if (!SSL_IS_DTLS(s)) { tls1.2-min-seclevel2.patch-- /* SSLv3 not allowed at level 2 */ tls1.2-min-seclevel2.patch-- if (nid <= SSL3_VERSION && level >= 2) tls1.2-min-seclevel2.patch-- return 0; tls1.2-min-seclevel2.patch-- /* TLS v1.1 and above only for level 3 */ tls1.2-min-seclevel2.patch-- if (nid <= TLS1_VERSION && level >= 3) tls1.2-min-seclevel2.patch-- return 0; tls1.2-min-seclevel2.patch-- /* TLS v1.2 only for level 4 and above */ tls1.2-min-seclevel2.patch-- if (nid <= TLS1_1_VERSION && level >= 4) tls1.2-min-seclevel2.patch-+ /* TLS v1.2 only for level 2 and above */ tls1.2-min-seclevel2.patch-+ if (nid <= TLS1_1_VERSION && level >= 2) tls1.2-min-seclevel2.patch- return 0; tls1.2-min-seclevel2.patch- } else { tls1.2-min-seclevel2.patch:- /* DTLS v1.2 only for level 4 and above */ tls1.2-min-seclevel2.patch:- if (DTLS_VERSION_LT(nid, DTLS1_2_VERSION) && level >= 4) tls1.2-min-seclevel2.patch:+ /* DTLS v1.2 only for level 2 and above */ tls1.2-min-seclevel2.patch:+ if (DTLS_VERSION_LT(nid, DTLS1_2_VERSION) && level >= 2) tls1.2-min-seclevel2.patch- return 0; tls1.2-min-seclevel2.patch- } tls1.2-min-seclevel2.patch- break; Since https://gitlab.com/openconnect/openconnect/-/merge_requests/158, the `--allow-obsolete-crypto` flag is supposed to set the OpenSSL security level to ZERO. Does adding this flag make the test pass when using the Ubuntu-distributed libraries? We decided in https://gitlab.com/openconnect/openconnect/-/issues/211#note_492787698 that *unconditionally* setting the OpenSSL security level to ZERO was not a good idea. If Debian-based distros are now preventing old/bad/Cisco DTLS from working, then we're definitely going to have to update our docs to reflect this. And maybe rethink the decision not to unconditionally set to zero. Dan _______________________________________________ openconnect-devel mailing list openconnect-devel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/openconnect-devel
