Package: stunnel4 Version: 3:5.06-2 Severity: normal Hello,
I have been running stunnel4 as a nc/socat replacement that can do SNI. However, since migrating to jessie, the setup fails. I managed to reproduce the problem: $ cat conf foreground = yes client = yes connect = nm.debian.org:443 $ cat req GET / HTTP/1.0 Host: nm.debian.org:443 Connection: close $ cat req | stunnel4 conf | head 2015.05.28 10:40:50 LOG5[20631]: stunnel 5.06 on x86_64-pc-linux-gnu platform 2015.05.28 10:40:50 LOG5[20631]: Compiled with OpenSSL 1.0.1j 15 Oct 2014 2015.05.28 10:40:50 LOG5[20631]: Running with OpenSSL 1.0.2a 19 Mar 2015 2015.05.28 10:40:50 LOG5[20631]: Update OpenSSL shared libraries or rebuild stunnel 2015.05.28 10:40:50 LOG5[20631]: Threading:PTHREAD Sockets:POLL,IPv6,SYSTEMD SSL:ENGINE,OCSP,FIPS Auth:LIBWRAP 2015.05.28 10:40:50 LOG5[20631]: Reading configuration from file conf 2015.05.28 10:40:50 LOG5[20631]: FIPS mode disabled 2015.05.28 10:40:50 LOG5[20631]: Configuration successful 2015.05.28 10:40:50 LOG5[20631]: Service [stunnel] accepted connection 2015.05.28 10:40:50 LOG5[20631]: s_connect: connected 206.12.19.123:443 2015.05.28 10:40:50 LOG5[20631]: Service [stunnel] connected remote server from 192.168.178.36:33262 2015.05.28 10:40:50 LOG3[20631]: INTERNAL ERROR: s_poll_wait returned 0, but no descriptor is ready 2015.05.28 10:40:50 LOG5[20631]: Connection reset: 58 byte(s) sent to SSL, 0 byte(s) sent to socket And this is a suboptimal workaround: $ (cat req; sleep 2) | stunnel4 conf | head 2015.05.28 10:40:55 LOG5[20640]: stunnel 5.06 on x86_64-pc-linux-gnu platform 2015.05.28 10:40:55 LOG5[20640]: Compiled with OpenSSL 1.0.1j 15 Oct 2014 2015.05.28 10:40:55 LOG5[20640]: Running with OpenSSL 1.0.2a 19 Mar 2015 2015.05.28 10:40:55 LOG5[20640]: Update OpenSSL shared libraries or rebuild stunnel 2015.05.28 10:40:55 LOG5[20640]: Threading:PTHREAD Sockets:POLL,IPv6,SYSTEMD SSL:ENGINE,OCSP,FIPS Auth:LIBWRAP 2015.05.28 10:40:55 LOG5[20640]: Reading configuration from file conf 2015.05.28 10:40:55 LOG5[20640]: FIPS mode disabled 2015.05.28 10:40:55 LOG5[20640]: Configuration successful 2015.05.28 10:40:55 LOG5[20640]: Service [stunnel] accepted connection 2015.05.28 10:40:55 LOG5[20640]: s_connect: connected 206.12.19.123:443 2015.05.28 10:40:55 LOG5[20640]: Service [stunnel] connected remote server from 192.168.178.36:33263 HTTP/1.1 200 OK Date: Thu, 28 May 2015 08:40:56 GMT Server: Apache Vary: Cookie,Accept-Language Content-Language: en-gb Set-Cookie: csrftoken=0KNKz1n1yXhQvExbispJtCaw8WfOkdo9; expires=Thu, 26-May-2016 08:40:56 GMT; Max-Age=31449600; Path=/ Strict-Transport-Security: max-age=15552000 X-Clacks-Overhead: GNU Terry Pratchett Connection: close Content-Type: text/html; charset=utf-8 2015.05.28 10:40:56 LOG3[20640]: INTERNAL ERROR: s_poll_wait returned 0, but no descriptor is ready 2015.05.28 10:40:56 LOG5[20640]: Connection reset: 58 byte(s) sent to SSL, 392 byte(s) sent to socket The bug seems likely to be here: https://github.com/copiousfreetime/stunnel/blob/master/src/client.c#L512 I guess s_poll_wait returns to notify of EOF on the input, but since in that case none of the sockets can read or write, it errors out. I deployed the sleep workaround in production, but it's slow and racey. There are unfortunately a surprisingly small amount of tools that can do this job and support SNI :( Thank you, Enrico -- System Information: Debian Release: stretch/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.19.0-trunk-amd64 (SMP w/4 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages stunnel4 depends on: ii adduser 3.113+nmu3 ii libc6 2.19-18 ii libssl1.0.0 1.0.2a-1 ii libsystemd0 215-17 ii libwrap0 7.6.q-25 ii multiarch-support 2.19-18 ii netbase 5.3 ii openssl 1.0.2a-1 ii perl 5.20.2-6 ii perl-modules 5.20.2-6 stunnel4 recommends no packages. Versions of packages stunnel4 suggests: pn logcheck-database <none> -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
