With the lastest update to stunnel 5.44-2.fc27, it appears to be unable to bind to localhost: $ cat stunnel.test debug = 6 syslog = no foreground = yes [test] client = yes protocol = smtp accept = localhost:12345 connect = localhost:2025 $ stunnel stunnel.test [ ] Clients allowed=500 [.] stunnel 5.44 on x86_64-redhat-linux-gnu platform [.] Compiled/running with OpenSSL 1.1.0g-fips 2 Nov 2017 [.] Threading:PTHREAD Sockets:POLL,IPv6 TLS:ENGINE,FIPS,OCSP,PSK,SNI Auth:LIBWRAP [ ] errno: (*__errno_location ()) [.] Reading configuration from file /home/christian/stunnel.test [.] UTF-8 byte order mark not detected [.] FIPS mode disabled [ ] Compression disabled [ ] Snagged 64 random bytes from /home/christian/.rnd [ ] Wrote 1024 new random bytes to /home/christian/.rnd [ ] PRNG seeded successfully [ ] Initializing service [test] [ ] Ciphers: PROFILE=SYSTEM [ ] TLS options: 0x02020004 (+0x02000000, -0x00000000) [ ] No certificate or private key specified [:] Service [test] needs authentication to prevent MITM attacks [.] Configuration successful [ ] Binding service [test] [ ] Listening file descriptor created (FD=6) [ ] Option SO_REUSEADDR set on accept socket [ ] Service [test] (FD=6) bound to 127.0.0.1:12345 [ ] Listening file descriptor created (FD=7) [ ] Option SO_REUSEADDR set on accept socket [!] bind: Address already in use (98) [!] Error binding service [test] to 127.0.0.1:12345 [ ] Unbinding service [test] [ ] Service [test] closed (FD=6) [ ] Service [test] closed There's (really) nothing listening on port 12345 here; and there are no SELinux warnings either. How reproducible: always Steps to Reproduce: 1. Update to stunnel 5.44-2.fc27 2. Start stunnel to bind to an unused port on localhost 3. bind: Address already in use (98) Actual results: [!] bind: Address already in use (98) [!] Error binding service [test] to 127.0.0.1:12345 Expected results: stunnel should bind to the port. Additional info: Downgrading to stunnel 5.42-1.fc27 helps (thanks for "dnf downgrade"!): $ sudo dnf downgrade stunnel $ stunnel stunnel.test 2018.02.05 23:42:26 LOG5[ui]: stunnel 5.42 on x86_64-redhat-linux-gnu platform 2018.02.05 23:42:26 LOG5[ui]: Compiled with OpenSSL 1.1.0f-fips 25 May 2017 2018.02.05 23:42:26 LOG5[ui]: Running with OpenSSL 1.1.0g-fips 2 Nov 2017 2018.02.05 23:42:26 LOG5[ui]: Update OpenSSL shared libraries or rebuild stunnel 2018.02.05 23:42:26 LOG5[ui]: Threading:PTHREAD Sockets:POLL,IPv6 TLS:ENGINE,FIPS,OCSP,PSK,SNI Auth:LIBWRAP 2018.02.05 23:42:26 LOG5[ui]: Reading configuration from file /home/christian/stunnel.test 2018.02.05 23:42:26 LOG5[ui]: UTF-8 byte order mark not detected 2018.02.05 23:42:26 LOG5[ui]: FIPS mode disabled 2018.02.05 23:42:26 LOG6[ui]: Initializing service [test] 2018.02.05 23:42:26 LOG4[ui]: Service [test] needs authentication to prevent MITM attacks 2018.02.05 23:42:26 LOG5[ui]: Configuration successful
Should have done this before reporting here: The same happens for the upstream version 5.44 (but not for 5.43!), so it's not Fedora specific. The changelog tipped me off: > https://www.stunnel.org/sdf_ChangeLog.html > Bugfixes > Default accept address restored to INADDR_ANY. The diff between these two version was small enough and after a bit of searching....with the following fix applied to 5.44, stunnel is able to bind to localhost again: --- src/options.c.orig 2017-11-14 23:06:12.000000000 -0800 +++ src/options.c 2018-02-06 00:01:58.892498016 -0800 @@ -1151,7 +1151,7 @@ NOEXPORT char *parse_service_option(CMD /* accept */ switch(cmd) { case CMD_BEGIN: - addrlist_clear(§ion->local_addr, 1); + addrlist_clear(§ion->local_addr, 0); break; case CMD_EXEC: if(strcasecmp(opt, "accept")) == Workaround: use a numeric address for localhost ("127.0.0.1" or "::1" will do) in the configuration file to have stunnel-5.44 bind to localhost: $ grep ^accept stunnel.test accept = ::1:12345 $ /usr/bin/stunnel stunnel.test 2018.02.06 00:13:20 LOG5[ui]: stunnel 5.44 on x86_64-redhat-linux-gnu platform 2018.02.06 00:13:20 LOG5[ui]: Compiled/running with OpenSSL 1.1.0g-fips 2 Nov 2017 2018.02.06 00:13:20 LOG5[ui]: Threading:PTHREAD Sockets:POLL,IPv6 TLS:ENGINE,FIPS,OCSP,PSK,SNI Auth:LIBWRAP 2018.02.06 00:13:20 LOG5[ui]: Reading configuration from file /home/christian/stunnel.test 2018.02.06 00:13:20 LOG5[ui]: UTF-8 byte order mark not detected 2018.02.06 00:13:20 LOG5[ui]: FIPS mode disabled 2018.02.06 00:13:20 LOG6[ui]: Initializing service [test] 2018.02.06 00:13:20 LOG4[ui]: Service [test] needs authentication to prevent MITM attacks 2018.02.06 00:13:20 LOG5[ui]: Configuration successful The downside with this workaround is, that the client port (:12345) can now only be reached with either the configured IPv4 or IPv6 localhost address, but not both. With stunnel-5.43 and "accept=localhost:12345", it would serve both 127.0.0.1 and ::1.
Created attachment 1391876 [details] allow stunnel to bind to localhost again
Would you be able to report the issue on the upstream mailing list? https://www.stunnel.org/cgi-bin/mailman/listinfo/stunnel-users
Yeah, good idea, should've done this from the start, sorry for the noise: https://www.stunnel.org/pipermail/stunnel-users/2018-February/005935.html
The issue has been fixed with stunnel-5.45b2, which is available from the stunnel website. I tried to "cherry-pick" the relevant changes and attached it to this bug, or one could wait until 5.45 is released, or just use the beta version :-)
Created attachment 1395772 [details] diff to stunnel-5.44 with only the changes that should fix this particular issue.
stunnel-5.44-5.fc27 has been submitted as an update to Fedora 27. https://bodhi.fedoraproject.org/updates/FEDORA-2018-6d8f240360
stunnel-5.44-5.fc26 has been submitted as an update to Fedora 26. https://bodhi.fedoraproject.org/updates/FEDORA-2018-37a01354b4
stunnel-5.44-5.fc26 has been pushed to the Fedora 26 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2018-37a01354b4
stunnel-5.44-5.fc27 has been pushed to the Fedora 27 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2018-6d8f240360
Yes, this fixes this bug - thanks! (Also: is it preferred for the reporter to state this in this bug report or is it sufficient/preferred to do so on Bodhi? The latter may produce less emails to the subscribers to this bug, I guess)
Bodhi should be sufficient.
stunnel-5.44-5.fc26 has been pushed to the Fedora 26 stable repository. If problems still persist, please make note of it in this bug report.
stunnel-5.44-5.fc27 has been pushed to the Fedora 27 stable repository. If problems still persist, please make note of it in this bug report.
Upstream recently released version 5.45 which includes this fix. But then shortly after that they released version 5.46 which contains this in the changelog: "Default accept address restored to INADDR_ANY". Christian, could you please verify that the version 5.46 does not break this again? Here is a scratch build to test: https://koji.fedoraproject.org/koji/taskinfo?taskID=27274049
My testing with the configuration from the bug description works fine, I just want to be sure we do not regress.
I did not have a very exotic stunnel configuration, so I tested the configuration file that I was initially using, basically the stunnel.test in comment 0. * stunnel-5.43 still works with that config. * stunnel-5.44 (unfixed) fails, as reported. * stunnel-5.44-5.fc28.x86_64 works. * stunnel 5.46 (vanilla) works. * stunnel-5.46-1.fc27 works too: $ wget https://kojipkgs.fedoraproject.org//work/tasks/4052/27274052/stunnel-5.46-1.fc27.x86_64.rpm $ rpm2cpio stunnel-5.46-1.fc27.x86_64.rpm | cpio -idv $ LD_LIBRARY_PATH=./usr/lib64/stunnel ./usr/bin/stunnel stunnel.test 2018.05.29 21:15:27 LOG5[ui]: stunnel 5.46 on x86_64-redhat-linux-gnu platform 2018.05.29 21:15:27 LOG5[ui]: Compiled/running with OpenSSL 1.1.0h-fips 27 Mar 2018 2018.05.29 21:15:27 LOG5[ui]: Threading:PTHREAD Sockets:POLL,IPv6 TLS:ENGINE,FIPS,OCSP,PSK,SNI Auth:LIBWRAP 2018.05.29 21:15:27 LOG5[ui]: Reading configuration from file /home/christian/s/stunnel.test 2018.05.29 21:15:27 LOG5[ui]: UTF-8 byte order mark not detected 2018.05.29 21:15:27 LOG5[ui]: FIPS mode disabled 2018.05.29 21:15:27 LOG6[ui]: Initializing service [test] 2018.05.29 21:15:27 LOG4[ui]: Service [test] needs authentication to prevent MITM attacks 2018.05.29 21:15:27 LOG5[ui]: Configuration successful 2018.05.29 21:15:27 LOG6[ui]: Service [test] (FD=6) bound to ::1:12345 2018.05.29 21:15:27 LOG6[ui]: Service [test] (FD=7) bound to 127.0.0.1:12345 $ netstat -an | grep 12345 tcp 0 0 127.0.0.1:12345 0.0.0.0:* LISTEN tcp6 0 0 ::1:12345 :::* LISTEN Specifying numeric IPv4 or IPv6 addresses in the configuration file works too and stunnel will then only listen on the configured address, as configured. So, I think your release is good to go :-) Thanks for checking!