Hi,
Sorry to be the bearer of a "those OS vendors did something again and now we have to catch up with them... again..." type of news, but, well, the maintainers of the Debian package of OpenSSL upgraded it to a prerelease 1.1.1 version and, in the process, changed the default cipher selection in the openssl.cnf file to 'SECLEVEL=2'.
Unfortunately, this means that the server certificate used in the stunnel test suite is not considered strong enough, so the test suite is failing. More details may be found in the description of the Debian bug https://bugs.debian.org/906981 and the error message itself is at https://ci.debian.net/data/autopkgtest/testing/amd64/s/stunnel4/865956/log.g... (look for all the lines containing "SSL_CTX_use_certificate:ca md too weak")
So my first reaction was to stop running the stunnel test suite and only leave my functional test script; however, I then had another idea and tried to get the stunnel test suite to explicitly specify SECLEVEL=1 using the attached patch. This actually helped a bit - it made most of the tests pass - but then I hit a problem with e.g. 037_failover_prio1: if there is a "ciphers" option in the config file, stunnel eventually dies with an error that I seem to remember having seen before; take a look at this gdb backtrace from stunnel 5.48:
(gdb) bt #0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51 #1 0x00007f0a349882f1 in __GI_abort () at abort.c:79 #2 0x000055b1aa3ad645 in fatal_debug (txt=0x55b1aa3c503c "Bad magic", file=0x55b1aa3ca6dd "ssl.c", line=118) at log.c:379 #3 0x000055b1aa3ae066 in get_alloc_list_ptr (ptr=0x7f0a24014520, file=0x55b1aa3ca6dd "ssl.c", line=118) at str.c:429 #4 0x000055b1aa3ae229 in str_detach_debug (ptr=ptr@entry=0x7f0a24014520, file=file@entry=0x55b1aa3ca6dd "ssl.c", line=line@entry=118) at str.c:378 #5 0x000055b1aa3ae884 in str_detach_debug (line=118, file=0x55b1aa3ca6dd "ssl.c", ptr=0x7f0a24014520) at str.c:413 #6 str_free_debug (ptr=0x7f0a24014520, file=0x55b1aa3ca6dd "ssl.c", line=118) at str.c:413 #7 0x00007f0a34f7661a in CRYPTO_free_ex_data () from /usr/lib/x86_64-linux-gnu/libcrypto.so.1.1 #8 0x00007f0a35112a98 in SSL_SESSION_free () from /usr/lib/x86_64-linux-gnu/libssl.so.1.1 #9 0x00007f0a34f7a1bc in OPENSSL_LH_doall_arg () from /usr/lib/x86_64-linux-gnu/libcrypto.so.1.1 #10 0x00007f0a35114177 in SSL_CTX_flush_sessions () from /usr/lib/x86_64-linux-gnu/libssl.so.1.1 #11 0x000055b1aa3c3701 in unbind_ports () at stunnel.c:439 #12 0x000055b1aa3c3799 in main_cleanup () at stunnel.c:224 #13 0x000055b1aa3ad720 in main (argc=<optimized out>, argv=<optimized out>) at ui_unix.c:79 (gdb)
(the line numbers may be a bit off from the stock stunnel source, since I also added a setrlimit(RLIMIT_CORE, infinity) patch)
So, yeah, what would be the best way forward here? I guess I might create a new certificate specifically for the Debian package's test suite, but I think the double-free problem may also need to be fixed. Let me know if you need any more information about reproducing it or any more data in case it doesn't happen on your end.
Thanks for everything you're doing for stunnel, and keep up the great work!
G'luck, Peter
On 8/24/18 6:15 PM, Peter Pentchev wrote:
Sorry to be the bearer of a "those OS vendors did something again and now we have to catch up with them... again..." type of news, but, well, the maintainers of the Debian package of OpenSSL upgraded it to a prerelease 1.1.1 version and, in the process, changed the default cipher selection in the openssl.cnf file to 'SECLEVEL=2'.
Debian indeed has a history of making strange changes to OpenSSL and thus breaking compatibility with the upstream package. I honestly don't think it is fair to call those modified packages "OpenSSL".
Regardless of Debian, we will update the test certificates to use sha256.
if there is a "ciphers" option in the config file, stunnel eventually dies with an error that I seem to remember having seen before; take a look at this gdb backtrace from stunnel 5.48:
This is a separate issue. I believe I manged to fix it. Please try: https://www.stunnel.org/downloads/beta/stunnel-5.49b4.tar.gz
So, yeah, what would be the best way forward here?
I think the best way is wait a few days for the updated upstream stunnel package, and then proceed with packaging it. Would it be okay with you?
Best regards, Mike
On Sun, Aug 26, 2018 at 09:35:28PM +0200, Michal Trojnara wrote:
On 8/24/18 6:15 PM, Peter Pentchev wrote:
Sorry to be the bearer of a "those OS vendors did something again and now we have to catch up with them... again..." type of news, but, well, the maintainers of the Debian package of OpenSSL upgraded it to a prerelease 1.1.1 version and, in the process, changed the default cipher selection in the openssl.cnf file to 'SECLEVEL=2'.
Debian indeed has a history of making strange changes to OpenSSL and thus breaking compatibility with the upstream package. I honestly don't think it is fair to call those modified packages "OpenSSL".
I cannot say I disagree completely...
Regardless of Debian, we will update the test certificates to use sha256.
Thanks!
if there is a "ciphers" option in the config file, stunnel eventually dies with an error that I seem to remember having seen before; take a look at this gdb backtrace from stunnel 5.48:
This is a separate issue. I believe I manged to fix it. Please try: https://www.stunnel.org/downloads/beta/stunnel-5.49b4.tar.gz
Yes, the changes between b3 and b4 do indeed fix this problem; many thanks for the quick reaction!
So, yeah, what would be the best way forward here?
I think the best way is wait a few days for the updated upstream stunnel package, and then proceed with packaging it. Would it be okay with you?
Of course, there is no hurry; apologies if my previous message somehow made it sound like there was any urgency. Thank you once again for all your work and for your understanding!
G'luck, Peter
-
Michal Trojnara -
Peter Pentchev