jamie sez:
> <snip> The only downside to this that I can
> see is that using stunnel in daemon mode I don't get concurrency limits
> or any of the other tcpserver benefits for the initial ssl connections.
> I could run stunnel out of xinetd I suppose but then I wouldn't get the
> ssl caching hoo-ha that stunnel can do.
I poked around a bit, and there's a (much) earlier thread on this list about
running stunnel under tcpserver--apparently the reason stunnel and tcpserver
don't (didn't?) get along is that stunnel wants to be argv[0]. There's a
patch for stunnel (from 1998, so it probably needs to be modified for the
current version). There's also an argv0 program that comes with ucspi-tcp
that also looks like it would solve the problem. Finally, there are a few
sample startup scripts that imply that that's not really a problem anymore,
and stunnel and tcpserver coexist fine.
>From searching the archive at <http://www-archive.ornl.gov:8000/> for
"tcpserver stunnel":
A message describing the problem, which sounds like what I saw, is at:
<http://www.ornl.gov/its/archives/mailing-lists/qmail/1998/09/msg00723.html>
The message with the (old) patch:
<http://www.ornl.gov/its/archives/mailing-lists/qmail/1998/09/msg00743.html>
A very informative message from this May, with a cool stunnel startup
script, implying that stunnel will indeed run under tcpserver:
<http://www.ornl.gov/its/archives/mailing-lists/qmail/2000/05/msg01621.html>
That last message also implies that qmail-smtpd will run under stunnel
without modification. I'll try these things out when I get a chance, and
report back to y'all.
> So what's the general thought on just adding TLS/SSL support
> to tcpserver,
> is that outside of the ucspi-tcp model, better left up to a separate
> program, or something that would be nice but just hasn't been
> done yet?
I'd guess that DJB feels it's better left up to a separate program, but I'm
sure there are others more qualified to give an opinion--anyone?
- Bradey
