Stunnel waits for a long time if client does not negotiate SSL
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
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 On Tue, Aug 7, 2012 at 3:47 PM, Denis Solovyov <elk@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
_______________________________________________ stunnel-users mailing list stunnel-users@stunnel.org https://www.stunnel.org/cgi-bin/mailman/listinfo/stunnel-users
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@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
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@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
participants (2)
-
Brian Wilkins -
Denis Solovyov