-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Mark and Michael,
On 4/24/20 07:24, Michael Osipov wrote: > Am 2020-04-24 um 08:57 schrieb Mark Thomas: >> On 24/04/2020 00:45, Michael Osipov wrote: >>> Folks, >>> >>> I run test from Tomcat master and libtcnative master on >>> FreeBSD, RHEL 7 and HP-UX 11.31 on a regular basis and noticed >>> that the OpenSSL 1.0.2 packages provided by Red Hat and HPE are >>> modified which make several tests fail. See an excerpt here >>> [1]. To verify this I have compiled OpenSSL from >>> OpenSSL_1_0_2-stable on FreeBSD w/o any modification and all >>> tests pass, so other must have modified OpenSSL. >>> >>> What is our position in terms of support/testing for modified >>> OpenSSL packages from OS vendors? Should we add a big fat >>> warning somewhere? Add this to tcnative README that we >>> test/recommend upstream only? >> >> The good news is that the tests that are failing are the ones I >> would expect to fail. >> >> When we added the code that lets us use OpenSSL syntax to define >> ciphers for JSSE (and JSSE syntax to define ciphers for OpenSSL) >> we added a these tests to ensure that we correctly tracked things >> like "ALL", "DEFAULT" as well as "ECDHE" etc. These are a moving >> target as support for new ciphers is added and ciphers viewed as >> less secure are removed. >> >> Our unit tests aim to work with the current version of all >> publicly supported OpenSSL branches. Currently, master (3.0.x) >> and 1.1.1. >> >> I expect the vendor supported 1.0.2 packages are close to current >> 1.1.1 but I wouldn't be surprised to see some minor differences. >> >> I think we have several options: - document the expectation more >> clearly so folks can more easily assess these failures - support >> using the vendor supported versions with the unit tests - provide >> a configuration option to skip these tests - detect vendor >> supplied OpenSSL and automatically skip the tests > > We need to do at least the documentation. As for detectection and > support: I consider this to be hardly solvable because there is no > identifier in "openssl version -a" which says I have been modified > by X. See: > >> $ openssl version -a OpenSSL 1.0.2r 26 Feb 2019 built on: >> reproducible build, date unspecified platform: hpux-ia64-cc >> options: bn(64,64) rc4(idx,int) des(idx,risc1,16,long) >> blowfish(idx) compiler: cc -I. -I.. -I../include >> -I/ssh_ssl_build/ssl-build/OpenSSL_1_0_FIPS_205/build/zlib +Z >> -DOPENSSL_PIC -DZLIB -DOPENSSL_THREADS -DDSO_DLFCN >> -DHAVE_DLFCN_H -D_REENTRANT -Ae +DD32 +O2 +Olit=all -z -DB_ENDIAN >> -D_REENTRANT -DOPENSSL_BN_ASM_MONT -DRC4_ASM -DSHA1_ASM >> -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DGHASH_ASM >> OPENSSLDIR: "/opt/openssl" > > and > >> $ openssl version -a OpenSSL 1.0.2k-fips 26 Jan 2017 built on: >> reproducible build, date unspecified platform: linux-x86_64 >> options: bn(64,64) md2(int) rc4(16x,int) des(idx,cisc,16,int) >> idea(int) blowfish(idx) compiler: gcc -I. -I.. -I../include >> -fPIC -DOPENSSL_PIC -DZLIB -DOPENSSL_THREADS -D_REENTRANT >> -DDSO_DLFCN -DHAVE_DLFCN_H -DKRB5_MIT -m64 -DL_ENDIAN -Wall -O2 >> -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions >> -fstack-protector-strong --param=ssp-buffer-size=4 >> -grecord-gcc-switches -m64 -mtune=generic -Wa,--noexecstack >> -DPURIFY -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT >> -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DRC4_ASM -DSHA1_ASM >> -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM >> -DBSAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM -DECP_NISTZ256_ASM >> OPENSSLDIR: "/etc/pki/tls" engines: rdrand dynamic > > The only option I see is to check for OS name/LSB release, call > with depdency graph with ldd and check for libssl/libcrypto in > default locations, but this is really really ugly. > > Compared to OpenSSL 1.1.1 from FreeBSD base and OpenSSL 1.0.2 > compiled myself: >> $ openssl version -a OpenSSL 1.1.1e-freebsd 17 Mar 2020 built >> on: reproducible build, date unspecified platform: FreeBSD-amd64 >> options: bn(64,64) rc4(16x,int) des(int) idea(int) >> blowfish(ptr) compiler: clang OPENSSLDIR: "/etc/ssl" ENGINESDIR: >> "/usr/lib/engines" Seeding source: os-specific > > Granted, this one says in the version string it is from FreeBSD. > >> $ /tmp/openssl-1.0.2/bin/openssl version -a OpenSSL 1.0.2v-dev >> xx XXX xxxx built on: reproducible build, date unspecified >> platform: BSD-x86_64 options: bn(64,64) rc4(16x,int) >> des(idx,cisc,16,int) idea(int) blowfish(idx) compiler: cc -I. >> -I.. -I../include -fPIC -DOPENSSL_PIC -DOPENSSL_THREADS -pthread >> -D_THREAD_SAFE -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -DL_ENDIAN >> -O3 -Wall -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT >> -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DRC4_ASM -DSHA1_ASM >> -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM >> -DBSAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM -DECP_NISTZ256_ASM >> OPENSSLDIR: "/tmp/openssl-1.0.2/ssl" > >> There are probably a few options I've missed. >> >> I will add at this point that debugging a failure and figuring >> out the right fix hasn't always easy. >> >> I'm currently wondering if some sort of combination of the above >> might work. Detect vendor variations, handle them where we can >> recognise them and skip them where we don't. >> >> I think this needs some further thought. > > Please let me know if you need further assistance here! This comes down to algorithms which have been compiled-out of the library, right? So we just need to automatically skip tests which attempt to use those algorithms. Unfortunately, the whole point of the unit tests is to make sure we haven't missed anything. In order to both remove unsupported algorithms AND test whether the remaining algorithms are properly-mapped, we need ANOTHER implementation of the mapping, or something similar to cross-check the two. Somewhere, we have a /complete/ list of OpenSSL-specified names that we support. That can easily be dumped somewhere and sorted alphabetically. Then, "openssl ciphers 'ALL'" can be run, sorted, and compared to the sorted list we have. Anything which isn't in the "openssl ciphers 'ALL'" list can be removed from the list of cipher suites we test. AIUI, it's possible to individually-remove a cipher suite from the unit tests if it's known to be missing on the platform. We just need to make that process automated, right? - -chris -----BEGIN PGP SIGNATURE----- Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl6jFCcACgkQHPApP6U8 pFjNyg//fKMq4Rd221Fv8wInTwelFrqKP6qUqOI26ydpSbm0Hfbd4Cxq8MUOU0lp 0KyVzY9hbJZOiVZWjR2rIodBfv26EK8W4HlwOlUIybaxGcdqL9WDGI6aLkQyhmjQ liXCprZeHy/KauqiLYB3wc6IGOOM+dqXJ7lsjpaZOVTwBLqLu/11u6ij6oWUKqN1 JjtmpBcwDlk01Ek+d/YUXLJ7E5yzWoKzlogAtQpFQRZ2JrEiAL2h++jWS6jnf+CQ W45LwG72PgQG1ccTG5mCm6/nbTMeyXKTJ6kzGp0oo9o1k1uI4rFWsmQ9XhmGfkmA K9H2bXc7iksrTXYegyN6kOisfkNFQ6UEcHkEozIEuyySUksqwQiuK+LJHMcJ/rGf QJ6GnlOOp+RAjT7APhZw2s90VIxWI/wgJ0Wd0vfUdHbAtCuABpqNKYFLlnkA4LoK Fpwpryl4k13vOVW2uieRpllruEsNTcRMELNG6w4obtgkiFP+8Bs23Z3KPyCAFiQE I7Spaa9/KvlKRJ2VQDd0KxlU/F3pxFEBUOncIzqHBSjaWLaIGcBLS7fP66D2oekJ zFtoEoNas2do3flI5pd1U4kGSGqEqHlAnzNNtc/bSdD9KIRikJrpHu4HV3lxuZnk Zyt6mwt5hKoxZxWD6X4hPKxiq622TCDSBPsZ6w6A58mphi/ZF/8= =NXq8 -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
