Bug#561885: perdition: SSL (port 993 and 995) connections don't timeout
On Mon, 21 Dec 2009, Simon Horman ho...@verge.net.au wrote: I'm quite happy to consider replacing openssl with GNUTLS. Although I don't know if it would solve the problem at hand nor how many bonus problems it might create. My past experience is that converting from OpenSSL to GNUTLS is not THAT difficult, but maintaining a code base to support both via autoconf is quite painful. But I haven't done anything as intense as you in this regard. http://www.opengroup.org/onlinepubs/95399/functions/setsockopt.html The above URL documents how to use the SO_RCVTIMEO and SO_SNDTIMEO options of setsockopt(). http://74.125.153.132/search?q=cache:rEDEp2tvku8J:article.gmane.org/gmane.network.gnutls.general/227+GNUTLS_E_AGAIN+timeoutcd=9hl=enct=clnk The above URL states that the way to set timeouts on the GNUTLS handshake (and presumably other GNUTLS library calls) is to use setsockopt(). I expect that you can use setsockopt() with OpenSSL too. While it's pretty stupid to not have a simple timeout parameter for a function call such as the ones we are discussing, it would be totally stupid to have no way at all of specifying a timeout other than SIGALRM. -- russ...@coker.com.au http://etbe.coker.com.au/ My Main Blog http://doc.coker.com.au/ My Documents Blog -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#561885: perdition: SSL (port 993 and 995) connections don't timeout
On Mon, Dec 21, 2009 at 08:49:59PM +1100, Russell Coker wrote: On Mon, 21 Dec 2009, Simon Horman ho...@verge.net.au wrote: I'm quite happy to consider replacing openssl with GNUTLS. Although I don't know if it would solve the problem at hand nor how many bonus problems it might create. My past experience is that converting from OpenSSL to GNUTLS is not THAT difficult, but maintaining a code base to support both via autoconf is quite painful. But I haven't done anything as intense as you in this regard. Hopefully GNUTLS could just replace OpenSSL. Having both available as a compile-time switch sounds painful. http://www.opengroup.org/onlinepubs/95399/functions/setsockopt.html The above URL documents how to use the SO_RCVTIMEO and SO_SNDTIMEO options of setsockopt(). http://74.125.153.132/search?q=cache:rEDEp2tvku8J:article.gmane.org/gmane.network.gnutls.general/227+GNUTLS_E_AGAIN+timeoutcd=9hl=enct=clnk The above URL states that the way to set timeouts on the GNUTLS handshake (and presumably other GNUTLS library calls) is to use setsockopt(). I expect that you can use setsockopt() with OpenSSL too. While it's pretty stupid to not have a simple timeout parameter for a function call such as the ones we are discussing, it would be totally stupid to have no way at all of specifying a timeout other than SIGALRM. Thanks for the pointers, I'll poke and see if that works for the problem at hand. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#561885: perdition: SSL (port 993 and 995) connections don't timeout
On Mon, Dec 21, 2009 at 11:08:15PM +1100, Simon Horman wrote:
On Mon, Dec 21, 2009 at 08:49:59PM +1100, Russell Coker wrote:
On Mon, 21 Dec 2009, Simon Horman ho...@verge.net.au wrote:
I'm quite happy to consider replacing openssl with GNUTLS.
Although I don't know if it would solve the problem at hand
nor how many bonus problems it might create.
My past experience is that converting from OpenSSL to GNUTLS is not THAT
difficult, but maintaining a code base to support both via autoconf is
quite
painful. But I haven't done anything as intense as you in this regard.
Hopefully GNUTLS could just replace OpenSSL.
Having both available as a compile-time switch sounds painful.
http://www.opengroup.org/onlinepubs/95399/functions/setsockopt.html
The above URL documents how to use the SO_RCVTIMEO and SO_SNDTIMEO options
of
setsockopt().
http://74.125.153.132/search?q=cache:rEDEp2tvku8J:article.gmane.org/gmane.network.gnutls.general/227+GNUTLS_E_AGAIN+timeoutcd=9hl=enct=clnk
The above URL states that the way to set timeouts on the GNUTLS handshake
(and
presumably other GNUTLS library calls) is to use setsockopt().
I expect that you can use setsockopt() with OpenSSL too. While it's pretty
stupid to not have a simple timeout parameter for a function call such as
the
ones we are discussing, it would be totally stupid to have no way at all of
specifying a timeout other than SIGALRM.
Thanks for the pointers, I'll poke and see if that works for the
problem at hand.
Hi Russell,
the patch below should resolve this problem. It applies against 1.18.
1.18 has a new --authenticate_timeout option which takes affect
during authentication, and is the timeout in effect in this case.
Due to the small amount of plumbing added for authenticate_timeout this
patch doesn't apply cleanly to 1.17. But if necessary you should
be able to get it to work by using opt.timeout instead of
io_get_timeout(io).
--
ssl: honour timeout during setup
Use setsockopt to enforce an idle timeout during SSL setup.
Thanks to Russell Coker for finding this problem and suggesting this fix.
Cc: Russell Coker russ...@coker.com.au
Signed-off-by: Simon Horman ho...@verge.net.au
Index: perdition/perdition/ssl.c
===
--- perdition.orig/perdition/ssl.c 2009-12-22 11:18:57.0 +1100
+++ perdition/perdition/ssl.c 2009-12-22 11:26:37.0 +1100
@@ -937,6 +937,48 @@ leave:
}
+static int set_socket_timeout(int s, long timeout)
+{
+ struct timeval tv = { .tv_sec = timeout, .tv_usec = 0 };
+
+ if (setsockopt(s, SOL_SOCKET, SO_RCVTIMEO, tv, sizeof(tv))) {
+ VANESSA_LOGGER_DEBUG_ERRNO(setcockopt);
+ return -1;
+ }
+
+ return 0;
+}
+
+static int io_set_socket_timeout(io_t *io, long timeout)
+{
+int s;
+
+s = io_get_rfd(io);
+if (s 0) {
+VANESSA_LOGGER_DEBUG(io_get_rfd);
+return -1;
+}
+
+if (set_socket_timeout(s, timeout) 0) {
+VANESSA_LOGGER_DEBUG(set_socket_timeout(rfd));
+return -1;
+}
+
+s = io_get_wfd(io);
+if (s 0) {
+VANESSA_LOGGER_DEBUG(io_get_wfd);
+return -1;
+}
+
+if (set_socket_timeout(s, timeout) 0) {
+VANESSA_LOGGER_DEBUG(set_socket_timeout(wfd));
+return -1;
+}
+
+return 0;
+}
+
+
/**
* __perdition_ssl_connection
* Change a stdio based connection into an SSL connection
@@ -959,6 +1001,7 @@ static io_t *__perdition_ssl_connection(
io_t *new_io = NULL;
SSL *ssl = NULL;
int ret;
+ long timeout;
ssl = SSL_new(ssl_ctx);
if (!ssl) {
@@ -974,10 +1017,17 @@ static io_t *__perdition_ssl_connection(
goto bail;
}
- io_set_timeout(new_io, io_get_timeout(io));
+ timeout = io_get_timeout(io);
+
+ io_set_timeout(new_io, timeout);
io_destroy(io);
io = NULL;
+ if (io_set_socket_timeout(new_io, timeout) 0) {
+ VANESSA_LOGGER_DEBUG(io_set_socket_timeout(timeout));
+ goto bail;
+ }
+
/* Get for TLS/SSL handshake */
if (flag PERDITION_SSL_CLIENT) {
SSL_set_connect_state(ssl);
@@ -994,11 +1044,16 @@ static io_t *__perdition_ssl_connection(
if (ret = 0) {
PERDITION_DEBUG_SSL_IO_ERR(SSL_accept,
io_get_ssl(new_io), ret);
- VANESSA_LOGGER_DEBUG(no shared ciphers?);
+ VANESSA_LOGGER_DEBUG(timeout or no shared ciphers?);
goto bail;
}
}
+
Bug#561885: perdition: SSL (port 993 and 995) connections don't timeout
Package: perdition Version: 1.17.1-2 Severity: normal I have Perdition running on an AMD64 system. Here is what happens with an idle port 110 session: # date ; telnet server0 110 ; date Sun Dec 20 23:30:34 GMT 2009 Trying 10.0.0.21... Connected to server0. Escape character is '^]'. +OK POP3 Ready server0 0001d0b1 Connection closed by foreign host. Mon Dec 21 00:00:34 GMT 2009 The default timeout is 1800s, and port 110 is working exactly as desired. Here is what happens with a port 995 session: # date ; telnet server0 995 ; date Sun Dec 20 23:30:40 GMT 2009 Trying 10.0.0.21... Connected to server0. Escape character is '^]'. The session does not get closed. It's now 51 minutes past the time when the session should have timed out, and it shows no signs of ending. Due to some problems with clients I have some sessions that last for weeks with no activity - apparently due to this problem. This wouldn't be a problem if it was only a few sessions, but I can get 500+ connections to a single server in that state and swap starts being used. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#561885: perdition: SSL (port 993 and 995) connections don't timeout
On Mon, Dec 21, 2009 at 11:54:25AM +1100, Russell Coker wrote: Package: perdition Version: 1.17.1-2 Severity: normal I have Perdition running on an AMD64 system. Here is what happens with an idle port 110 session: # date ; telnet server0 110 ; date Sun Dec 20 23:30:34 GMT 2009 Trying 10.0.0.21... Connected to server0. Escape character is '^]'. +OK POP3 Ready server0 0001d0b1 Connection closed by foreign host. Mon Dec 21 00:00:34 GMT 2009 The default timeout is 1800s, and port 110 is working exactly as desired. Here is what happens with a port 995 session: # date ; telnet server0 995 ; date Sun Dec 20 23:30:40 GMT 2009 Trying 10.0.0.21... Connected to server0. Escape character is '^]'. The session does not get closed. It's now 51 minutes past the time when the session should have timed out, and it shows no signs of ending. Due to some problems with clients I have some sessions that last for weeks with no activity - apparently due to this problem. This wouldn't be a problem if it was only a few sessions, but I can get 500+ connections to a single server in that state and swap starts being used. Hi Russell, In the case of the test that you ran above it looks like the code is waiting forever inside the openssl call SSL_accept() which is made in __perdition_ssl_connection(). The timeouts in perdition actually only operate on select() and pre-date the introduction of SSL. I'm scratching my head for a fix for this one. Any suggestions would be welcome. I'm hoping not to have to resort to setitimer(). -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#561885: perdition: SSL (port 993 and 995) connections don't timeout
On Mon, 21 Dec 2009, Simon Horman ho...@verge.net.au wrote: In the case of the test that you ran above it looks like the code is waiting forever inside the openssl call SSL_accept() which is made in __perdition_ssl_connection(). The timeouts in perdition actually only operate on select() and pre-date the introduction of SSL. I'm scratching my head for a fix for this one. Any suggestions would be welcome. I'm hoping not to have to resort to setitimer(). That was pretty much the response I expected. But when filing such a bug report one always hopes that the maintainer or upstream developer will have some secret knowledge that allows an easy fix. Is GNUTLS any better in this regard? I won't rule out the possibility of submitting a patch to replace openssl with gnutls if you would be willing to accept it. NB I'm not making any commitment to write such a patch, I'm overloaded at the moment and most things I want to do don't get done. -- russ...@coker.com.au http://etbe.coker.com.au/ My Main Blog http://doc.coker.com.au/ My Documents Blog -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#561885: perdition: SSL (port 993 and 995) connections don't timeout
On Mon, Dec 21, 2009 at 04:02:05PM +1100, Russell Coker wrote: On Mon, 21 Dec 2009, Simon Horman ho...@verge.net.au wrote: In the case of the test that you ran above it looks like the code is waiting forever inside the openssl call SSL_accept() which is made in __perdition_ssl_connection(). The timeouts in perdition actually only operate on select() and pre-date the introduction of SSL. I'm scratching my head for a fix for this one. Any suggestions would be welcome. I'm hoping not to have to resort to setitimer(). That was pretty much the response I expected. But when filing such a bug report one always hopes that the maintainer or upstream developer will have some secret knowledge that allows an easy fix. Unfortunately no secret knowledge this time. Is GNUTLS any better in this regard? I won't rule out the possibility of submitting a patch to replace openssl with gnutls if you would be willing to accept it. NB I'm not making any commitment to write such a patch, I'm overloaded at the moment and most things I want to do don't get done. I'm quite happy to consider replacing openssl with GNUTLS. Although I don't know if it would solve the problem at hand nor how many bonus problems it might create. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
