[stunnel-users] Stunnel waits for a long time if client does not negotiate SSL

[Denis Solovyov]

Making experiments I also discovered that legal pop3 (not pop3s) clients
accidentally trying to connect to pop3s port served by stunnel caused
long time waiting as well. They just can't negotiate SSL, cancel the
connection on client's side but it remains established on server...

# ps -C stunnel -o pid,etime,cmd
  PID     ELAPSED CMD
10264    20:05:07 stunnel /usr/local/etc/stunnel/pop3s.conf
17025    19:42:41 stunnel /usr/local/etc/stunnel/pop3s.conf

This is not good, definitely not good... :(

SSL negotiation timeout would solve the problem, but to invent a
workaraund please give me a hint - what exactly part of linux is
responsible for this? Is it stunnels only fault? Or is it OpenSSL issue
(not the most modern one on this machine)? Or maybe this is about TCP?
Can you reproduce the same effect?


>> stunnel thinks the pipe is still open until the peer closes it. 
>> Have you tried using the TIMEOUTidle or TIMEOUTbusy option?
>> http://www.stunnel.org/static/stunnel.html

> Yes, I wrote in my message that they didn't have effect, unfortunately
> (although of course expected to have). I set them to different values
> (for example, 10 or 60 sec), and connection just kept established for
> minutes. I can understand why it happens, I want to understand if there
> is a way to avoid it as this may cause bringing down an entire service,
> as far as I understand...

> For example, proftpd has different timeouts for login and idle. I'd
> appreciate "SSL negotiation timeout", but maybe there is another
> solution or even this is my local problem.

> I forgot to write that pop3 software was not started by stunnel at all
> here since SSL was not negotiated. Just a waiting stunnel process.


>> On Tue, Aug 7, 2012 at 3:47 PM, Denis Solovyov <elk at elk.ru> wrote:
>> Hello,

>> I use stunnel 4.53 to provide pop3s for existing pop3 service. I start
>> stunnel from xinetd, and then exec pop3 utility from stunnel.

>> If a legal pop3s client connects to a server, everything's fine. But if
>> I try to do "telnet host 995" with a simple telnet client and then just
>> do nothing (or even close telnet client without quitting) stunnel
>> process keeps waiting for a very long time (actually maybe forever, I
>> just kill it). The last line in log in such case "Service [stunnel]
>> accepted connection from xx.xx.xx.xx:xxxx". No stunnel TIMEOUT* options
>> have effect in this situation.

>> What can I do to avoid such "waiting"?
>> Maybe stunnel should have something like "SSL negotiation timeout"?  Or
>> is there a way to emulate it? (Analyzing `ps` or `netstat` is a bad idea
>> of course.)

With the best regards,
Denis Solovyov