October 2011 - stunnel-users

Stunnel 4 failing to connect to gmail
by Asif Iqbal 11 Dec '20

11 Dec '20

I am faling to connect to gmail. Not sure what that bind error means. iqbala@ghar:~$ sudo stunnel4 2008.12.15 13:53:17 LOG7[3839:3083650736]: Snagged 64 random bytes from /home/iqbala/.rnd 2008.12.15 13:53:17 LOG7[3839:3083650736]: Wrote 1024 new random bytes to /home/iqbala/.rnd 2008.12.15 13:53:17 LOG7[3839:3083650736]: RAND_status claims sufficient entropy for the PRNG 2008.12.15 13:53:17 LOG7[3839:3083650736]: PRNG seeded successfully 2008.12.15 13:53:17 LOG7[3839:3083650736]: Certificate: /etc/stunnel/stunnel.pem 2008.12.15 13:53:17 LOG7[3839:3083650736]: Certificate loaded 2008.12.15 13:53:17 LOG7[3839:3083650736]: Key file: /etc/stunnel/stunnel.pem 2008.12.15 13:53:17 LOG7[3839:3083650736]: Private key loaded 2008.12.15 13:53:17 LOG7[3839:3083650736]: SSL context initialized for service ssmtp 2008.12.15 13:53:17 LOG5[3839:3083650736]: stunnel 4.22 on i486-pc-linux-gnu with OpenSSL 0.9.8g 19 Oct 2007 2008.12.15 13:53:17 LOG5[3839:3083650736]: Threading:PTHREAD SSL:ENGINE Sockets:POLL,IPv6 Auth:LIBWRAP 2008.12.15 13:53:17 LOG6[3839:3083650736]: file ulimit = 1024 (can be changed with 'ulimit -n') 2008.12.15 13:53:17 LOG6[3839:3083650736]: poll() used - no FD_SETSIZE limit for file descriptors 2008.12.15 13:53:17 LOG5[3839:3083650736]: 500 clients allowed 2008.12.15 13:53:17 LOG7[3839:3083650736]: FD 10 in non-blocking mode 2008.12.15 13:53:17 LOG7[3839:3083650736]: FD 11 in non-blocking mode 2008.12.15 13:53:17 LOG7[3839:3083650736]: FD 12 in non-blocking mode 2008.12.15 13:53:17 LOG7[3839:3083650736]: SO_REUSEADDR option set on accept socket 2008.12.15 13:53:17 LOG3[3839:3083650736]: Error binding ssmtp to 74.125.93.111:587 2008.12.15 13:53:17 LOG3[3839:3083650736]: bind: Cannot assign requested address (99) Here is how my conf file looks like iqbala@ghar:~$ cat /etc/stunnel/stunnel.conf | egrep -v "^;|^$" cert = /etc/stunnel/stunnel.pem foreground = yes sslVersion = SSLv3 chroot = /var/lib/stunnel4/ setuid = stunnel4 setgid = stunnel4 pid = /stunnel4.pid socket = l:TCP_NODELAY=1 socket = r:TCP_NODELAY=1 debug = 7 output = /var/log/stunnel4/stunnel.log client = yes [ssmtp] accept = smtp.gmail.com:587 connect = 25 Asif Iqbal PGP Key: 0xE62693C5 KeyServer: pgp.mit.edu

5 9

stunnel and hosts.allow
by Yousef Alhashemi 06 Jul '16

06 Jul '16

Hi, This may be a little bit off-topic, but does anyone here use stunnel with pan? My connections to stunnel (in pan) are always refused by libwrap. I was looking for the right rule to add to /etc/hosts.allow but nothing seems to work aside from "ALL : ALL" (which is obviously not good) and "nntps: KNOWN". Is the latter reasonable? The hosts_access(5) manpage is confusing to say the least. It mentions that daemon (the first token on any line) is the name of the daemon running the process, which would be "stunnel" in my case, but using "stunnel : LOCAL" or even "stunnel : ALL" doesn't work. The rule that seems to work, as mentioned, is "nntps : KNOWN" ("nntps" being the group name in stunnel.conf). What's even more confusing to me is that "nntps : LOCAL" does not work either. Nor does "nntps : localhost 127.0.0.1", "nntps : localhost", "nntps : 127.0.0.1", or "nntps : 192.168.1.". Pan is running on the same machine as stunnel so all connections must be coming from localhost. Why do these rules not trigger? Either way, I'd like to know the "least permissive" hosts.allow rule that would allow me to connect to my news provider from pan, and/or whether "nntps : KNOWN" is a safe option. Thanks, Yousef

3 6

stunnel.conf in %USERAPPDATA%
by Sebastian Rose-Indorf 20 Mar '12

20 Mar '12

Hello, I use Stunnel with Windows. The configuration file "stunnel.conf" and the log file "stunnel.log" are in the %USERAPPDATA%\Stunnel folder. Stunnel starts and works without problems. But the GUI options "Edit stunnel.conf" and "Reload stunnel.conf" do not work. Is remedy possible? Sebastian

2 3

patch for using stunnel as client with pkcs11-engine and opensc smartcard
by Märt Laak 30 Jan '12

30 Jan '12

Dear stunnel managers, I would like to inform you that there exist some incompatibility with stunnel and openssl pkcs11-engine with external PIN entry device (like RSA smartcard using opensc) in Linux. We use this config to load openssl engine stunnel.conf: --- engine=dynamic engineCtrl=SO_PATH:/usr/lib/engines/engine_pkcs11.so engineCtrl=ID:pkcs11 engineCtrl=LIST_ADD:1 engineCtrl=LOAD engineCtrl=MODULE_PATH:/usr/lib/opensc-pkcs11.so engineCtrl=INIT --- Problem is, with this setup stunnel does not allow user to enter PIN for the secret key. Instead it tries to get secret key without PIN, 3 times (and then therefore usually blocks card PIN) and retires: ---- Initializing engine 1 Engine 1 initialized PRNG seeded successfully Certificate: mart.pem Certificate loaded Key file: id_01 error queue: 26096080 : error:26096080:engine routines:ENGINE_load_private_key:failed loading private key error queue: 800050A0 : error:800050A0:PKCS11 library:PKCS11_login:PIN incorrect Wrong PIN: retrying error queue: 26096080 : error:26096080:engine routines:ENGINE_load_private_key:failed loading private key error queue: 800050A0 : error:800050A0:PKCS11 library:PKCS11_login:PIN incorrect Wrong PIN: retrying error queue: 26096080 : error:26096080:engine routines:ENGINE_load_private_key:failed loading private key ENGINE_load_private_key: 800050A0: error:800050A0:PKCS11 library:PKCS11_login:PIN incorrect ---- I discovered workaround that is valid form version 4.26 till current 4.34, as follows, NULL-ing the ui_data.method property in ctx.c: --- diff -cr stunnel-4.34/src/ctx.c stunnel-4.34-patched/src/ctx.c *** stunnel-4.34/src/ctx.c 2010-09-14 18:08:43.000000000 +0300 --- stunnel-4.34-patched/src/ctx.c 2010-09-28 21:56:36.219081931 +0300 *************** *** 304,309 **** --- 304,310 ---- UI_method_set_reader(ui_method, pin_cb); #else /* USE_WIN32 */ ui_method=UI_OpenSSL(); + ui_data.section = NULL; #endif /* USE_WIN32 */ if(section->engine) for(i=1; i<=3; i++) { --- After that patch private key loads correctly: --- Initializing engine 1 Engine 1 initialized PRNG seeded successfully Certificate: mart.pem Certificate loaded Key file: id_01 private key loaded --- It would be nice if: * somebody investigates more precisely why the OpenSSL PIN entry is not showing with unpached stunnel * include my or better patch for this situation Thank you very much for excellent piece of software! With best regards, Märt Laak

2 2

Error detected on socket (read) file descriptor: Broken pipe (32)
by Alex Magee 08 Nov '11

08 Nov '11

Hello, I'm trying to use stunnel to workaround a wine bug which prevents an old Windows mail client from accessing my mail server through a pop3s 995 port. I'm not an expert on linux, stunnel, sockets or ssl. The process seems to start off well, establishes a connection to the correct remote mail server, and negotiates an ssl connection, but then terminates with: Error detected on socket (read) file descriptor: Broken pipe (32) I've played with various settings in the stunnel.conf file, but with no success. A Google search turned up one other example of this problem back in Nov 2010, but no solution was forthcoming. Does anyone have any suggestions of what might be the problem? The level 7 debug stunnel.log file follows at the end, with TCP addresses masked. The system is SUSE Linux 11.4. Using the latest versions of ssl and stunnel. Thanks, Alex stunnel.log -------------- local socket: FD=0 allocated (non-blocking mode) Service pmail-pop3 accepted FD=0 from 127.0.0.1:48828 Service pmail-pop3 started Option TCP_NODELAY set on local socket Service pmail-pop3 accepted connection from 127.0.0.1:48828 remote socket: FD=1 allocated (non-blocking mode) connect_blocking: connecting xxx.xxx.xxx.xxx:995 connect_blocking: s_poll_wait xxx.xxx.xxx.xxx:995: waiting 10 seconds connect_blocking: connected xxx.xxx.xxx.xxx:995 Service pmail-pop3 connected remote server from 192.168.1.47:46187 Remote FD=1 initialized Option TCP_NODELAY set on remote socket SNI: host name: yyy.yyy.yyy..com SSL state (connect): before/connect initialization SSL state (connect): SSLv3 write client hello A SSL state (connect): SSLv3 read server hello A SSL state (connect): SSLv3 read server certificate A SSL state (connect): SSLv3 read server done A SSL state (connect): SSLv3 write client key exchange A SSL state (connect): SSLv3 write change cipher spec A SSL state (connect): SSLv3 write finished A SSL state (connect): SSLv3 flush data SSL state (connect): SSLv3 read finished A 1 items in the session cache 1 client connects (SSL_connect()) 1 client connects that finished 0 client renegotiations requested 0 server connects (SSL_accept()) 0 server connects that finished 0 server renegotiations requested 0 session cache hits 0 external session cache hits 0 session cache misses 0 session cache timeouts SSL connected: new session negotiated Negotiated ciphers: RC4-SHA SSLv3 Kx=RSA Au=RSA Enc=RC4(128) Mac=SHA1 Socket closed on read Sending SSL write shutdown Error detected on socket (read) file descriptor: Broken pipe (32) Connection reset: 79 bytes sent to SSL, 64 bytes sent to socket Service pmail-pop3 finished (0 left) str_stats: 0 block(s), 0 byte(s)

2 2

Why does verify=3 require the entire cert chain to be present in cafile?
by al_9x＠yahoo.com 04 Nov '11

04 Nov '11

If the leaf (server) cert is declared trusted (added to the cafile), there is no point in walking the trust chain.

5 15

[PATCH] Unix socket tunnelling
by Antoine Catton 03 Nov '11

03 Nov '11

Hi, I was looking for solution for tunneling a MySQL socket through encrypted IPv6. And I found this bunch of patches for stunnel <http://www.exceliance.fr/download/free/patches/stunnel/unix-sockets/>. Unfortunately, there's no patch for stunnel 4.44. So I rebased it in order to make it work (I attached it to this email). FYI, I’m not the author of this patch, I just adapted it for stunnel 4.44. The author seems to be this french company <http://www.exceliance.fr/en>. I just glanced over it, I didn't review it. Anyway, I think it would be a great thing to integrate it into stunnel in order to avoid rebasing the patch for every stunnel new version. Besides, it is a very useful feature. Integrating this patch would imply updating the documentation of stunnel configuration. As far as I know it add another general option “unix-sockets-dir” which is “/var/run/” by default. All the socket path must start by a slash, and this path will be appended to “unix-sockets-dir” option. Thank you. Regards, -- Antoine Catton Nexedi Intern

2 1

FD_MAX question
by Eckert, Doug 27 Oct '11

27 Oct '11

Greetings, We're using stunnel-4.15-2.el5.1 as provided on the RHEL 5 update 7 distro. Is there any way to override the FD_MAX setting (64 IIRC), perhaps as a stunnel.conf option? Doug Eckert Technical Architect Global Business & Technology Services Dow Jones | A News Corporation Company P.O. Box 300 | Princeton NJ 08543-0300 (W) 609.520.4993 (C) 732.666.3681 Email: doug.eckert(a)dowjones.com<mailto:alias@dowjones.com> [cid:image001.png@01CC93D6.2E9FF0E0]

3 4

Re: [stunnel-users] Why does verify=3 require the entire cert chain to be present in cafile?
by Jochen Bern 27 Oct '11

27 Oct '11

On 10/25/2011 09:54 PM, al_9x(a)yahoo.com wrote: > verify=3 means checking is done against local certs. My point is that > if the actual server cert is stored locally (i.e. trusted) that should > be enough. When I put just the server cert in cafile validation (and > connection) fails, but when I put the whole chain, it succeeds. Why > isn't the server cert sufficient? Mostly guessing here, but: 1. stunnel uses the OpenSSL libraries. The verify(1) manpage says: "The verify program uses the same functions as the internal SSL and S/MIME verification, therefore this description applies to these verify operations too. [...] The verify operation consists of a number of separate steps. Firstly a certificate chain is built up starting from the supplied certificate and ending in the root CA. It is an error if the whole chain cannot be built up. The chain is built up by looking up the issuers certificate of the current certificate. If a certificate is found which is its own issuer it is assumed to be the root CA." -- http://www.openssl.org/docs/apps/verify.html#VERIFY_OPERATION So I'd guess that the algorithm you're at odds with is part of OpenSSL, rather than something stunnel can change. 2. Certificates are to be considered invalid once they have been revoked, and in order to check the CRL, you have to determine the issuing CA. Whose certificate has to be checked against its parent CA, etc. all the way to the Root CA. A "verification" mechanism which does not check for explicit revocation would have to be considered faulty for *most*, if not all, application cases - the fact that automated CRL checking is still pretty much absent in mechanisms which do not *mandate* a working Internet connection notwithstanding. 3. Since you're apparently trying to set up a point-to-point SSL connection with preconfigured direct trust, my guess would be that you'd be better off if the server would use a self-signed cert (either altogether, or in addition to the current one - say, on an additional port). However, since you never mentioned what kind of software you're trying to get to talk to each other, I'm at a loss suggesting *how* you might do that. 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

2 2

Re: [stunnel-users] Why does verify=3 require the entire cert chain to be present in cafile?
by Jean-Yves F. Barbier 26 Oct '11

26 Oct '11

On Tue, 25 Oct 2011 15:54:26 -0400 al_9x(a)yahoo.com wrote: ... > verify=3 means checking is done against local certs. My point is that > if the actual server cert is stored locally (i.e. trusted) that should > be enough. When I put just the server cert in cafile validation (and > connection) fails, but when I put the whole chain, it succeeds. Why > isn't the server cert sufficient? Because the SVR cert is used to signed your own cert, this ensure liability between svr & cli; and if it was only the SVR cert, how could you revoke client by client? You would be obliged to revoke all clients at once - which doesn't look like a very good strategy if you've got 1000's of clients... -- You will be dead within a year.

3 2