[stunnel-users] Problems SSLifying an "exec" Service without KeepAlive

[Jochen Bern]

Hello everyone, today I tried to set up network access to a service
using stunnel 4.35. The underlying service, by default, exits after
every request+reply. When running stunnel in daemon mode, this seems to
upset things such that subsequent connections hang. I cannot quite
pinpoint whether it's a config problem, design (of my setup) problem, or
bug, so any help's welcome ...

More info:

The underlying service accesses a Nagios' livestatus interface

http://mathias-kettner.de/checkmk_livestatus.html#H1:Remote%20access%20to%20Livestatus

using the "unixcat" tool provided. Unless you specifically request
connection keepalives, unixcat will close/exit after answering one
request, *or* timing out waiting for one. That "exit procedure", AFAICT,
isn't different from what the imapd or pppd in the stunnel(8) manpage's
EXAMPLES section do ...

I need to secure access to the service, so I'm throwing client cert
verification and libwrap at the connections. The current daemon mode
configuration (with several commented-out attempts) reads, slightly
anonymized:
client=no
verify=3
pid=/var/run/stunnel/livestatus.pid
#setuid=stunnel
#socket = a:SO_REUSEADDR=0
#foreground= yes

[livestatus]

accept = [...PORT...]

cert = [...SERVER...].pem
key = [...SERVER...].key
CAfile = [...CA...].pem
CApath = [...TempStagingDirectory...]

exec = /usr/local/bin/unixcat
execargs = unixcat /var/lib/nagios3/rw/live
pty = yes

retry = no
session = 3

#TIMEOUTclose = 0
#TIMEOUTbusy = 5
#TIMEOUTidle = 5

# openssl s_client -CAfile [...CA...].pem -showcerts \

-connect [...SERVER...]:[...PORT...] -cert [...CLIENT...].cert \
-key [...CLIENT...].key -state

CONNECTED(00000003)
SSL_connect:before/connect initialization
SSL_connect:SSLv2/v3 write client hello A
SSL_connect:SSLv3 read server hello A

[...]

SSL handshake has read 1743 bytes and written 1933 bytes
---
New, TLSv1/SSLv3, Cipher is AES256-SHA
Server public key is 1024 bit
Compression: NONE
Expansion: NONE
Protocol : TLSv1
Cipher : AES256-SHA
Session-ID: 1B4221E2917E3BD49AA2102C2CCE60A624DB256D6B4D61F9D0D77EA843DC31BC
Master-Key: 57E6DF8E7E0A741B718E356467450DD00969465295A9C6FE03416ED16E74AF93058EC168EF6DF1B9F3F637F505FF6EF4
Key-Arg : None
Start Time: 1298390481
Timeout : 300 (sec)
Verify return code: 0 (ok)
---

At that point, I can type in one request, then unixcat terminates,

read:errno=104
LOG5[30042:139819109037792]: Reading configuration from file /etc/stunnel/livestatus.conf
LOG5[30042:139819109037792]: Peer certificate location [...TempStagingDirectory...]
LOG5[30042:139819109037792]: Configuration successful
LOG5[30042:139819109037792]: No limit detected for the number of clients
LOG5[30043:139819109037792]: stunnel 4.35 on x86_64-unknown-linux-gnu with OpenSSL 0.9.8g 19 Oct 2007
LOG5[30043:139819109037792]: Threading:PTHREAD SSL:ENGINE Sockets:POLL,IPv6

[...]

LOG5[30043:1075198288]: Service livestatus accepted connection from [...CLIENT...]:39287
LOG5[30043:1075198288]: Certificate accepted: depth=1, [...CA...]
LOG5[30043:1075198288]: Certificate accepted: depth=0, [...CLIENT...]
LOG3[30043:1075198288]: readsocket: Input/output error (5)
LOG5[30043:1075198288]: Connection reset: 2293 bytes sent to SSL, 33 bytes sent to socket

Rerunning the exact same command stops dead after the

CONNECTED(00000003)

and manually "telnet"ing to the port from a different host doesn't
behave in a normal way (closing the connection after I type the first
line of non-SSL stuff) anymore, either. Running the unixcat command from
a local command line, however, still works normally.

I tried running stunnel off inetd, which seems to work, so I'd guess
it's the server-side SSL session cacheing which interferes. However, I
don't see any related stunnel config keywords in the manpage, and
stunnel offering a cached session to a connection *from a different
client host* sound odd to me, too ... ?

Kind regards,
J. Bern

[m***@gmail.com]

Hi Jochen,

Just curious, if you were able to get around this. I am also having similar trouble just running stunnel as a proxy for the local unix socket to provide ssl interface on the network; first connections succeed but the client thereafter have troubles.