Hi,
I've wanted to implement SSL on my INN 2.4.3 servers, but there were
problems with various clients hanging while posting articles (as discussed
on the list). Then I installed INN 2.4.4, and that one does work nicely -
except for the fact that I get accumulating nnrpd-ssl processes which
(sometimes) don't die when client hangs/goes away.

strace(1) shows they're stuck in blocking read(0,...)

Looking at the source, one sees nnrpd/line.c in line_read()
a comment in #ifdef HAVE_SSL which says:

 * Here, we decide to just bypass the select() wait.  Unlike
 * innd with multiple threads, the select on nnrpd is just
 * waiting on a single file descriptor, so it is not really
 * essential with blocked read like SSL_read.  Using an alarm
 * signal around SSL_read for non active timeout, SSL works
 * without dead locks.  However, without the select() wait,
 * the IDLE timer stat won't be collected...


However, the mentioned "alarm signal" around SSL_read is not implemented in
2.4.4. So instead, the dead connections could lead to nnrpd processes
waiting forever in SSL_read().

Attached inn-2.4.4_nnrpd_SSL_alarm.diff implements this alarm() call, making
inn.conf "clienttimeout" variable work also on SSL connections.

Also attached is inn-2.4.4_nnrpd_SSL_keepalive.diff which (on systems that
support it) implements SO_KEEPALIVE in SSL TCP connections, allowing system
detection and closing the dead TCP SSL connections automatically after
system-specified time (usually at least 2 hours as recommended by RFC; on
Linux see /proc/sys/net/ipv4/tcp_keepalive_*).

Either patch should fix the problems with nrrpd-ssl processes never dying
but each does address separate problem (and in separate ways). KEEPALIVE
patch detects dead connections, but ALARM patch implements clienttimeout
policy (which could, but might not, deal only with hanged connections).

I've done several tests and both patches seem to work nicely for me; but
I've never actively hacked innd code before, nor did I do any extensive
multi-system testing. On the other hand, they're both relatively simple; so
not much bugs could be there (famous last words :)

I'd recommend implementing both of them.

-- 
Opinions above are GNU-copylefted.