July 2015 - 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 05 Jul '16

05 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

"Chained" stunnel instances
by Michael Gebis 01 Aug '15

01 Aug '15

Hello. I have a question about a strange stunnel configuration; specifically, I'm like to use 'chained' stunnel instances, and I'm running into an issue. We have a conceptually simple setup: a client that connects to a server. We use stunnel both for encryption and for the failover mechanism. Here's a diagram of our simplest setup: /----S1 / C--st0-----S2 \ \----S3 We have a client that connects to stunnel. Our stunnel configuration lists three connections with "prio" failover mode. So usually, connections go from C thru st and onto Server 1. If S1 is down, st0 fails to connect to S1 and instead tries S2, and all is good. However, sometimes we may place an optional second instance of stunnel in front of the servers. /----st1--S1 / C--st0-----st2--S2 \ \----st3--S3 The failover mode of stunnel does not work so well in this configuration. If S1 is down, st0's failover algorithm does not kick in. Instead, st0 happily connects to st1, which is still alive and running. st1 then detects S1 is down and immediately closes the connection, but st0 does not care. Since the initial connection was successful, it does not initiate the failover algorithm. You may ask "why not change to round-robin mode?" The answer is that S1 is a dedicated machine, and S2/S3 are underpowered backups that have other primary responsibilities. We really want to direct all connections to S1 and only use S2/S3 in emergencies. You may also ask, "Why the second layer of stunnel?"--unfortunately, there are several hairy implementation-specific details that make this hard to change. My question is: is there any stunnel configuration option that can help us out? We would like the failover to work with and without the second layer of stunnel. From looking at the source code, I think I'm out of luck, but I figured it couldn't hurt to ask. Thanks! Michael

3 3

stunnel 5.21 - fails to listen on both IPv4/IPv6 (Linux)
by Lonnie Abelbeck 30 Jul '15

30 Jul '15

Very long-time user with the AstLinux project... stunnel 5.19 works fine, when upgrading to stunnel 5.21 with the same config I get: -- Starting Stunnel Server Proxy... [.] stunnel 5.21 on i586-pc-linux-gnu platform [.] Compiled/running with OpenSSL 1.0.1p 9 Jul 2015 [.] Threading:FORK Sockets:POLL,IPv6 TLS:ENGINE,OCSP,PSK,SNI [ ] errno: (*__errno_location ()) [.] Reading configuration from file /etc/stunnel/server.conf [.] UTF-8 byte order mark not detected [ ] Compression disabled [ ] PRNG seeded successfully [!] Error resolving "::": Address family for nodename not supported (EAI_ADDRFAMILY) [!] /etc/stunnel/server.conf:14: "accept = :::8443": Failed to resolve accepting address -- Has the syntax changed to listen on both IPv4/IPv6 ? Lonnie

2 2

Configuring stunnel on multi tenant server
by Saurabh Beriwal 30 Jul '15

30 Jul '15

Hi All, I want to configure stunnel on multi tenant server. Please let us know the best possible way to do this. Also is it OK if I keep multiple accept and connect parameters in stunnel configuration file. Thank you.

2 1

stunnel 5.22 released
by Michal Trojnara 30 Jul '15

30 Jul '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dear Users, I have released version 5.22 of stunnel. The ChangeLog entry: Version 5.22, 2015.07.30, urgency: HIGH * New features - "OCSPaia = yes" added to the configuration file templates. - Improved double free detection. * Bugfixes - Fixed a number of OCSP bugs. The most severe of those bugs caused stunnel to treat OCSP responses that failed OCSP_basic_verify() checks as if they were successful. - Fixed the passive IPv6 resolver (broken in stunnel 5.21). Home page: https://www.stunnel.org/ Download: https://www.stunnel.org/downloads.html SHA-256 hashes: 8ad628a6948153cdb2044283f6988384a30585ea7e14778c2ee616a6678cb83f stunnel-5.22.tar.gz 9b3fe70bcfeb64b013b7b926e475a7d100ef1fdf5ce352ad90ac1034f780ea2a stunnel-5.22-installer.exe 2f49313debe7af27feeab246a771dc513e5e368e1839e92fba4cfe0b2735aeba stunnel-5.22-android.zip Best regards, Mike -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJVufy2AAoJEC78f/DUFuAUHVYQAK+keyqWyllv3ky5hRi8DlXe LLtuUdTYTalI64Fg5/TYL6+fbrEjWoAWtGwg+X/muVNj7KW4twlKrakMtkDpSDNd 0xSh94/u/PCrPVThxCq7AUbTPLyrG6ox5RKYDkOKfyGQ3q5ix6yba0l6fQqHXPCr OAbaRuwn5U6u7lPxXa69ozwyY5JHIiGqhMfQJBRXwFoeNbWak3HM7+Pe5DZ0ACLa SRY0iCseR1aQ12pZaaNoknkAAL9kmHgRP+fuPFqKMkp8TgZ2469qg30s/Bzn7n0U h5GvAuhYkQdDDbC7ozWgqaNxRNpOe+3RZ50fpCueyAlZESe8agHcyXchoj4JUVx+ 5ihOms4WujamCtP4MzHrRo6eQpeoGbw1EZ2P//Q9TlxX4METgEfV0lzaR7n376jr y24xIFEMl2tnqJ81lKQZWlxAP4MiKZgr//GOueRewRCtYSSQcK/mHvxZMDFfHAc7 N2LUmzm+PpsHwto7VkUy1m4eEAb34Tr3QubzvrT1yD4YMQDR6tID+xkRmuJWjMhf qBcXecKetIQq70KuI+VVqJxdP3Ekgjb+xnNOSKelUP/TkHpvubjTViSIVPu+5DSb x2viDBKAbgWcER2aZsB6UWXfQwjT/apDhqu6XrwjAcFfBk0ul0QazmH0HMc9ouVd yziOHVATYgcXYcTIQvj9 =DTOg -----END PGP SIGNATURE-----

1 0

Questions between stunnel 4.56 and 5.21 (current version)
by Guy.Gaudreau.TCR06＠ssss.gouv.qc.ca 28 Jul '15

28 Jul '15

Will a 4.56 installation be able to establish a tunnel to a 5.21 version. Will a 5.21 installation be able to establsih a tunnel to a 4.56 version What happends If I have a server that is currently running a 4.56 version and we install the 5.21 version on the same server. Will both versions co-exist on the same server peacefully or will the install process uninstall the 4.56 version. in that last scenario will the tunnels already configured under versio 4.56 work under the 5.21 install? Thank you Guy Gaudreau

1 0

stunnel 5.21 released
by Michal Trojnara 27 Jul '15

27 Jul '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dear Users, I have released version 5.21 of stunnel. The ChangeLog entry: Version 5.21, 2015.07.27, urgency: MEDIUM * New features - Signal names are displayed instead of numbers. - First resolve IPv4 addresses on passive resolver requests. This speeds up stunnel startup on Win32 with a slow/defunct DNS service. - The "make check" target was modified to only build Win32 executables when stunnel is built from a git repository (thx to Peter Pentchev). - More elaborate descriptions were added to the warning about using "verify = 2" without "checkHost" or "checkIP". - Performance optimization was performed on the debug code. * Bugfixes - Fixed the FORK and UCONTEXT threading support. - Fixed "failover=prio" (broken since stunnel 5.15). - Added a retry when sleep(3) was interrupted by a signal in the cron thread scheduler. Home page: https://www.stunnel.org/ Download: https://www.stunnel.org/downloads.html SHA-256 hashes: 2aef568b1955f5e233f6a8e17ebce3d30755f1be44c813f5a48e621f785596e3 stunnel-5.21.tar.gz d5ec83140060af2b373a82abab0f7fd34c76a68c4f2990d46be460526b325de6 stunnel-5.21-installer.exe 2788d9e11b65dd4b111616bab1d7f09943916c924ba023cc3ad4260ac1f6f6d7 stunnel-5.21-android.zip Best regards, Mike -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJVtfz2AAoJEC78f/DUFuAUey4P/0tQ8yj3Yt7K5yLIorDGu9lI w95Vs2MtyOvFQyoX24dPKrDULKmxE28Dg8RJt51ZuT9q8mIfPdBA+jphyfjbpzl0 BeNQNbzEfN36dhOa2+dvr4+fcna/lnRpNMQg6sP/z4KHDLoI72lAg9vVwv5VX/4X JAMAaTxbrOXuXOmVPLSdHBeug7Y/0Q/+jPg9tSEslMtBaJvMd4CcHs4q8dCW9OQv AUWLtOiSsubfCvQ9rwGODObFJCA3BINrmh3a9EyhKJTov+8JKHlJY02r4zGJYMC4 PIVAVZWit9mEFefG6BuEWwOw4gohAInDXpsN2X9BNNDfUAVlUtp6OoxATcGv/H45 Uf25Dz2Bu8WtKIuuCIhN79PBfqSG8f2mSwNsec8OcYNOTzkAHKoFQQfKbJ1FUD5+ lTBhOFfo/B5haQA1EHNf0z8JxDulnsL7JsQQo4hF3ShSiCZpEAVvSkixpwCjm2kR WCtQ0w5eLccD/CnfjNrcOp3QKGLacZ+PCm9MH+cQDQvnmhAaelWK+OL67L9FKwBf hbJMA2RwwjN7efwEeUlnzVTBiJS9fsPTJghh8CzYuDWlnhEEnB9WX2FI1yVZVxM+ 8tGifpdOkRCFhpQSQkj0pWy/qf/cU8mL2uM31hBNcsRjCt6PfjQfKQ7jyMFvicmc rWJhvWvAfLAJXl+rgn5r =WvhQ -----END PGP SIGNATURE-----

1 0

Disable TLSv1
by Smith, Michael 23 Jul '15

23 Jul '15

I am running stunnel version 5.20. How do I disable TLSv1 and leave only TLSv1.2 and TSLv2 enabled? Michael Smith System Specialist II 281-283-2930

2 1

Question about behavior with "failover = prio"
by Michael Gebis 22 Jul '15

22 Jul '15

Hello again. We recently noticed a behavior in stunnel that surprised us, and seems to be inconsistent with the man page description. We use "failover = prio" in our configuration file. To refresh everyone's memory, the man page describes this option here: failover = rr | prio Failover strategy for multiple "connect" targets. rr (round robin) - fair load distribution prio (priority) - use the order specified in config file default: rr Our config file contains a list of connect targets, like this: [...] connect = h1.example.com connect = h2.example.com connect = h3.example.com connect = h4.example.com [...] Based on the description, we expect the connection to try h1 first, and if h1 fails, failover through the remainder of the list, in-order. However, what we observe is that the connections start at a seemingly random place in the list. It does appear to proceed in-order...it's just the starting place that seems incorrect. For example, we might get a sequence that proceeds "h3->h4->h1->h2". Please let me know if I am misunderstanding the intended behavior of the 'prio' failover strategy. Here is a trial patch that hard-codes the starting place for the failover to the beginning of the list. I am not sure if this change has any unintended consequences for other configurations. But as a proof-of-concept, it does seem to fix the behavior to be consistent with our reading of the man page. This patch is against 5.20 but it appears that 5.21b2 acts the same way. Thanks! Michael diff -ru stunnel-5.20.orig/src/client.c stunnel-5.20-prio-fix/src/client.c --- stunnel-5.20.orig/src/client.c 2015-07-16 15:55:52.213064746 -0700 +++ stunnel-5.20-prio-fix/src/client.c 2015-07-17 16:13:12.129184507 -0700 @@ -1285,7 +1285,8 @@ *c->connect_addr.rr_ptr=(i+1)%c->connect_addr.num; s_log(LOG_INFO, "failover: round-robin"); } else { - s_log(LOG_INFO, "failover: priority"); + s_log(LOG_INFO, "failover: priority, starting at first entry"); + i=0; } return i; }

2 1