stunnel4 with exec as service for securing pop3

I would like to run the stunnel4 daemon in order to provide a pop3s service by using a pop server (solid-pop3d). The following configuration file doesn't work (the pop3 server doesn't start, I think) and I would like to ask for any hints. --stunnel.conf>>> cert = /etc/stunnel/stunnel4.pem sslVersion = SSLv3 [pop3s] accept = 995 exec = /usr/sbin/solid-pop3d execargs = solid-pop3d <<<stunnel.conf-- I would expect stunnel4 to start up solid-pop3d every time someone connects to port 995 and communicate to solid-pop3d, just like inetd would do, if configured to serve solid-pop3d. By the way, I have opened the service "pop3s" in /etc/hosts.allow. Thanks in advance for any help. -- Best regards, Jörg-Volker.

2011/5/19 Jörg-Volker Peetz <jvpeetz@web.de> I would expect stunnel4 to start up solid-pop3d every time someone connects
to port 995 and communicate to solid-pop3d, just like inetd would do, if configured to serve solid-pop3d.
This may sound obvious, but does the log file say anything? ~Yousef

The relevant entries in the log file seem to me: 2011.05.19 14:02:39 LOG6[12493:140165894280960]: SSL accepted: new session negotiated 2011.05.19 14:02:39 LOG6[12493:140165894280960]: Negotiated ciphers: DHE-RSA-CAMELLIA256-SHA SSLv3 Kx=DH Au=RSA Enc=Camellia(256) Mac=SHA1 2011.05.19 14:02:39 LOG7[12493:140165894280960]: socket#1: FD=1 allocated (non-blocking mode) 2011.05.19 14:02:39 LOG7[12493:140165894280960]: socket#2: FD=2 allocated (non-blocking mode) 2011.05.19 14:02:39 LOG3[12493:140165894280960]: connect: Operation now in progress (115) 2011.05.19 14:02:39 LOG5[12493:140165894280960]: Connection reset: 0 bytes sent to SSL, 0 bytes sent to socket 2011.05.19 14:02:39 LOG7[12493:140165894280960]: Service pop3s finished (0 left) So, nothing relevant? -- Best regards, Jörg-Volker.

On Thu, May 19, 2011 at 12:59:41 +0200, Jörg-Volker Peetz wrote:
I would like to run the stunnel4 daemon in order to provide a pop3s service by using a pop server (solid-pop3d). The following configuration file doesn't work (the pop3 server doesn't start, I think) and I would like to ask for any hints.
--stunnel.conf>>>
cert = /etc/stunnel/stunnel4.pem
sslVersion = SSLv3
[pop3s] accept = 995 exec = /usr/sbin/solid-pop3d execargs = solid-pop3d
<<<stunnel.conf--
I would expect stunnel4 to start up solid-pop3d every time someone connects to port 995 and communicate to solid-pop3d, just like inetd would do, if configured to serve solid-pop3d.
By the way, I have opened the service "pop3s" in /etc/hosts.allow.
Thanks in advance for any help. [...]
Does /etc/hosts.allow contain an entry for solid-pop3d permitting connections from localhost? Cheers, rlr

Ross Richardson wrote, on 05/20/11 01:02:
<snip>
Does /etc/hosts.allow contain an entry for solid-pop3d permitting connections from localhost?
Cheers, rlr
I've put "pop3s", the name of the service in the stunnel config file, into /etc/hosts.allow. "solid-pop3d" itself is not linked against libwrap. By the way, if I let "solid-pop3d" run as a daemon itself and use connect = 100 instead of exec = /usr/sbin/solid-pop3d execargs = solid-pop3d in the config file the "pop3s" service works. But, as I said, "solid-pop3d" itself is not linked against libwrap and , therefor, accepts connections to port 110 from every host. To avoid this without running inetd with tcpd, I wanted stunnel to do the job of starting the pop3-server. From what I understood from the documentation, it should be possible. -- Best regards, Jörg-Volker.

On 05/20/2011 09:42 AM, Jörg-Volker Peetz wrote:
By the way, if I let "solid-pop3d" run as a daemon itself and use connect = 100 instead of exec = /usr/sbin/solid-pop3d execargs = solid-pop3d in the config file the "pop3s" service works. But, as I said, "solid-pop3d" itself is not linked against libwrap and , therefor, accepts connections to port 110 from every host.
(FWIW, in case you can't get things running the way you want, *this* problem should be rather trivial to solve; even if you cannot configure solid-pop3d to listen on 127.0.0.1:110 instead of 0.0.0.0:110, the host firewall ("iptables" in current Linux) can make short work of external connection attempts.) Kind regards, J. Bern -- Jochen Bern, Systemingenieur --- LINworks GmbH <http://www.LINworks.de/> Postfach 100121, 64201 Darmstadt | Robert-Koch-Str. 9, 64331 Weiterstadt PGP (1024D/4096g) FP = D18B 41B1 16C0 11BA 7F8C DCF7 E1D5 FAF4 444E 1C27 Tel. +49 6151 9067-231, Zentr. -0, Fax -299 - Amtsg. Darmstadt HRB 85202 Unternehmenssitz Weiterstadt, Geschäftsführer Metin Dogan, Oliver Michel

Jochen Bern wrote, on 05/20/11 09:58: <snip>
(FWIW, in case you can't get things running the way you want, *this* problem should be rather trivial to solve; even if you cannot configure solid-pop3d to listen on 127.0.0.1:110 instead of 0.0.0.0:110, the host firewall ("iptables" in current Linux) can make short work of external connection attempts.)
Kind regards, J. Bern
Yes indeed, that's also a resort. But I would like the minimalist solution ;-) Which is, stunnel provides ssl security plus (small) firewall for pop3. Also, I have the impression from the documentation that stunnel advertises to be able to provide this functionality. Maybe I've hit a bug in stunnel? Debian has a similar bug report #626856. I could provide further information on the problem I encounter, if required. -- Best regards, Jörg-Volker.

On Fri, May 20, 2011 at 11:14:22 +0200, Jörg-Volker Peetz wrote:
[...] Also, I have the impression from the documentation that stunnel advertises to be able to provide this functionality. Maybe I've hit a bug in stunnel? [...]
I seem to recall having tried it (successfully) in the past. Just another obvious suggestion: if using chroot, /usr/sbin/solid-pop3d is within the chroot hierarchy, isn't it? rlr

Yes, I also read in the Debian bug report #626856 that a bug was introduced with a recent version ov stunnel4. I haven't used chroot in my configuration, and I also read in the documentation that the service to be executed has to be located relative to the chroot directory. -- Best regards, Jörg-Volker.
participants (4)
-
Jochen Bern
-
Jörg-Volker Peetz
-
Ross Richardson
-
Yousef Alhashemi