June 2014 - 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

Server side SNI and Windows problem
by Slava 17 Aug '14

17 Aug '14

I'm trying use SNI on Windows (server 2003 R2 or XP) stunnel 5.01 on x86-pc-msvc-1500 platform Compiled/running with OpenSSL 1.0.1g-fips 7 Apr 2014 stunnel.config ... [main] accept = 60000 connect = 10.0.21.1:80 [ssh] connect = 10.0.21.1:22 sni=main:ssh Client has line sni=ssh, but server not see this and attempt connect to :80. I'm try connect from linux and windows, same result For server on linux all work fine. ?

3 4

Re: [stunnel-users] OpenSSL FIPS header not found - version 5.02
by Hui Yu 26 Jun '14

26 Jun '14

No, you don't need to do "make depend". Just follow my exact steps, it is enough to compile a FIPS enabled stunnel. I did it on the 64 bits centos linux (linux-x86_64) and redhat linux (linux-generic32) , so that is probably the only change you need. Good luck.

2 1

Re: [stunnel-users] OpenSSL FIPS header not found - version 5.02
by Hui Yu 26 Jun '14

26 Jun '14

You need to follow these steps: 1.1.1 Build openssl-fips package >From https://www.openssl.org/source/, download latest openssl-fips package and unzip under tar -zxvf openssl-fips-2.0.5.tar.gz<https://www.openssl.org/source/openssl-fips-2.0.5.tar.gz> cd /home/user/openssl-fips-2.0.5 /Configure --prefix=/usr/local linux-generic32 make make install 1.1.2 Build FIPS capable openssl package >From https://www.openssl.org/source/, download latest openssl package and unzip under tar -zxvf openssl-1.0.1h.tar.gz<https://www.openssl.org/source/openssl-1.0.1h.tar.gz> Cd /home/user/openssl-1.0.1h ./Configure --prefix=/usr/local --with-fipsdir=/usr/local fips linux-generic32 make CC=fipsld FIPSLD_CC=gcc -j 8 make install the binary openssl can be found at /usr/local/bin/openssl [root@ssl86 hyu]# openssl version OpenSSL 1.0.1h-fips 5 Jun 2014 #######here is tricky, go back to FIPS directory make install again. cd /home/user/openssl-fips-2.0.5 make install 1.1.3 Build stunnel package >From https://www.stunnel.org/downloads.html, Download latest stunnel version 5.02 package and unzip under tar -zxvf stunnel-5.02.tar.gz<https://www.stunnel.org/downloads/stunnel-5.02.tar.gz> cd /home/user/stunnel-5.02 ./configure --enable-fips --with-ssl=/usr/local/ --prefix=/usr/local make CC=fipsld FIPSLD_CC=gcc -j 8 make install the stunnel binary can be found at /usr/local/bin/stunnel

2 1

(no subject)
by Paulraj Samikannu 25 Jun '14

25 Jun '14

I see the following messages on the production server, any special log setting requirement or is our stunnel generating too many messages too fast? Jun 25 06:13:35 pprccmfaap001 rsyslogd-2177: imuxsock begins to drop messages from pid 171059 due to rate-limiting Jun 25 06:15:34 pprccmfaap001 rsyslogd-2177: imuxsock lost 47 messages from pid 171059 due to rate-limiting Jun 25 06:15:36 pprccmfaap001 rsyslogd-2177: imuxsock begins to drop messages from pid 171059 due to rate-limiting

4 6

public domain [PATCH] to stunnel v456 to clear SSL_OP_LEGACY_SERVER_CONNECT
by Simner, John 25 Jun '14

25 Jun '14

Dear Michal, Dear All, Please find attached a patch to stunnel 4.56 to clear SSL_OP_LEGACY_SERVER_CONNECT. There was a security requirement to ensure that the stunnel client could not connect to unpatched servers. I am aware from OpenSSL (https://www.openssl.org/docs/ssl/SSL_CTX_set_options.html ) that this parameter is currently set by default and has to be manually cleared by calling SSL_CTX_clear_options() or SSL_clear_options()if an OpenSSL client applications wants to ensure they can not connect to unpatched servers (and thus avoid any security issues). The attached patch achieves this. OpenSSL also state "As more servers become patched the option SSL_OP_LEGACY_SERVER_CONNECT will not be set by default in a future version of OpenSSL" so this patch is only required until OpenSSL change the default value. Thanks.. John [Unify: Harmonize your enterprise] John Simner BSc(Hons) MSc CEng. MIET Software Engineer, Devices Development Unify Enterprise Communications Ltd. Tel.: +44 (1908) 817378 (One Number Service) Email: john.simner(a)unify.com <mailto:[email protected]> www.unify.co.uk<http://www.unify.co.uk/> Follow us: [Social_media_icons] <http://www.unify.com/social-media> Unify Enterprise Communications Limited. Registered Office: Brickhill Street, Willen Lake, Milton Keynes, MK15 0DJ Registered No: 5903714, England. This email contains confidential information and is for the exclusive use of the addressee. If you are not the addressee then any distribution, copying, or use of this email is prohibited. If received in error, please advise the sender and delete immediately. We accept no liability for any loss or damage suffered by any person arising from use of this email.

1 0

Can not get TLS1.2 work in FIPS mode.
by Hui Yu 19 Jun '14

19 Jun '14

Hi all: Base on this link https://www.stunnel.org/sdf_ChangeLog.html, to make TLS 1.2 work, I need to put stunnel in FIPS enable mode. In stunnel config file, I have following to enable FIPS mode and select TLS 1.2. sslVersion=TLSv1.2 FIPS = yes But when my TLS 1.2 client send "client hello" with version TLS 1.2 to stunnel, stunnel still send "server hello" with TLS 1.0 back. Could somebody help on why stunnel does not support TLS 1.2 ? My stunnel is verstion 5.02, compiled with latest OpenSSL version 1.0.1h FIPS mode library. Following is the log file: ################### 2014.06.19 11:09:13 LOG7[15491]: Clients allowed=500 2014.06.19 11:09:13 LOG5[15491]: stunnel 5.02 on i686-pc-linux-gnu platform 2014.06.19 11:09:13 LOG5[15491]: Compiled with OpenSSL 1.1.0-fips-dev xx XXX xxxx 2014.06.19 11:09:13 LOG5[15491]: Running with OpenSSL 1.0.1h-fips 5 Jun 2014 2014.06.19 11:09:13 LOG5[15491]: Update OpenSSL shared libraries or rebuild stunnel 2014.06.19 11:09:13 LOG5[15491]: Threading:PTHREAD Sockets:POLL,IPv6 SSL:ENGINE,OCSP,FIPS Auth:LIBWRAP 2014.06.19 11:09:13 LOG7[15491]: errno: (*__errno_location ()) 2014.06.19 11:09:13 LOG5[15491]: Reading configuration from file stunnel.K.tacacs+.conf 2014.06.19 11:09:13 LOG5[15491]: FIPS mode enabled ##################FIPS mode enabled############ 2014.06.19 11:09:13 LOG7[15491]: Compression disabled 2014.06.19 11:09:13 LOG7[15491]: Snagged 64 random bytes from /root/.rnd 2014.06.19 11:09:13 LOG7[15491]: Wrote 1024 new random bytes to /root/.rnd 2014.06.19 11:09:13 LOG7[15491]: PRNG seeded successfully 2014.06.19 11:09:13 LOG6[15491]: Initializing service [encrypted_tacplus] 2014.06.19 11:09:13 LOG6[15491]: Loading cert from file: /tftpboot/cacert-hyu.pem 2014.06.19 11:09:13 LOG6[15491]: Loading key from file: /tftpboot/privkey-hyu.pem 2014.06.19 11:09:13 LOG4[15491]: Insecure file permissions on /tftpboot/privkey-hyu.pem 2014.06.19 11:09:13 LOG7[15491]: Private key check succeeded 2014.06.19 11:09:13 LOG7[15491]: DH initialization 2014.06.19 11:09:13 LOG7[15491]: Could not load DH parameters from /tftpboot/cacert-hyu.pem 2014.06.19 11:09:13 LOG7[15491]: Using hardcoded DH parameters 2014.06.19 11:09:13 LOG7[15491]: DH initialized with 2048-bit key 2014.06.19 11:09:13 LOG7[15491]: ECDH initialization 2014.06.19 11:09:13 LOG7[15491]: ECDH initialized with curve prime256v1 2014.06.19 11:09:13 LOG7[15491]: SSL options set: 0x00000004 2014.06.19 11:09:13 LOG5[15491]: Configuration successful 2014.06.19 11:09:13 LOG7[15491]: Service [encrypted_tacplus] (FD=7) bound to 0.0.0.0:2249 2014.06.19 11:09:14 LOG7[15491]: No pid file being created 2014.06.19 11:17:52 LOG7[15506]: Service [encrypted_tacplus] accepted (FD=3) from 10.25.105.82:636 2014.06.19 11:17:52 LOG7[15509]: Service [encrypted_tacplus] started 2014.06.19 11:17:52 LOG5[15509]: Service [encrypted_tacplus] accepted connection from 10.25.105.82:636 2014.06.19 11:17:52 LOG7[15509]: SSL state (accept): before/accept initialization 2014.06.19 11:17:52 LOG7[15509]: SNI: no virtual services defined 2014.06.19 11:17:52 LOG7[15509]: SSL state (accept): SSLv3 read client hello B ##########wireshark shows "client hello" version is TLS1.2, stunnel log shows it is TLS1.0. 2014.06.19 11:17:52 LOG7[15509]: SSL state (accept): SSLv3 write server hello A 2014.06.19 11:17:52 LOG7[15509]: SSL state (accept): SSLv3 write certificate A 2014.06.19 11:17:52 LOG7[15509]: SSL state (accept): SSLv3 write key exchange A 2014.06.19 11:17:52 LOG7[15509]: SSL state (accept): SSLv3 write server done A 2014.06.19 11:17:52 LOG7[15509]: SSL state (accept): SSLv3 flush data 2014.06.19 11:17:55 LOG7[15509]: SSL state (accept): SSLv3 read client key exchange A 2014.06.19 11:17:55 LOG7[15509]: SSL state (accept): SSLv3 read finished A 2014.06.19 11:17:55 LOG7[15509]: SSL state (accept): SSLv3 write change cipher spec A 2014.06.19 11:17:55 LOG7[15509]: SSL state (accept): SSLv3 write finished A 2014.06.19 11:17:55 LOG7[15509]: SSL state (accept): SSLv3 flush data 2014.06.19 11:17:55 LOG7[15509]: 1 items in the session cache 2014.06.19 11:17:55 LOG7[15509]: 0 client connects (SSL_connect()) 2014.06.19 11:17:55 LOG7[15509]: 0 client connects that finished 2014.06.19 11:17:55 LOG7[15509]: 0 client renegotiations requested 2014.06.19 11:17:55 LOG7[15509]: 1 server connects (SSL_accept()) 2014.06.19 11:17:55 LOG7[15509]: 1 server connects that finished 2014.06.19 11:17:55 LOG7[15509]: 0 server renegotiations requested 2014.06.19 11:17:55 LOG7[15509]: 0 session cache hits 2014.06.19 11:17:55 LOG7[15509]: 0 external session cache hits 2014.06.19 11:17:55 LOG7[15509]: 1 session cache misses 2014.06.19 11:17:55 LOG7[15509]: 0 session cache timeouts 2014.06.19 11:17:55 LOG6[15509]: No peer certificate received 2014.06.19 11:17:55 LOG6[15509]: SSL accepted: new session negotiated 2014.06.19 11:17:55 LOG6[15509]: Negotiated TLSv1/SSLv3 ciphersuite: DHE-RSA-AES128-SHA (128-bit encryption) ##############negotiated as TLS1.0 2014.06.19 11:17:55 LOG6[15509]: Compression: null, expansion: null 2014.06.19 11:17:55 LOG6[15509]: s_connect: connecting 127.0.0.1:2250 2014.06.19 11:17:55 LOG7[15509]: s_connect: s_poll_wait 127.0.0.1:2250: waiting 10 seconds 2014.06.19 11:17:55 LOG5[15509]: s_connect: connected 127.0.0.1:2250 2014.06.19 11:17:55 LOG5[15509]: Service [encrypted_tacplus] connected remote server from 127.0.0.1:47369 2014.06.19 11:17:55 LOG7[15509]: Remote socket (FD=8) initialized

1 0

Configure stunnel to clear SSL_OP_LEGACY_SERVER_CONNECT to prevent connections to unpatched servers.
by Simner, John 19 Jun '14

19 Jun '14

Hi, I have a requirement for a stunnel client built with openSSL 0.9.8y to not connect to unpatched servers. I know this is a simple matter of using SSL_CTX_clear_options(ctx, SSL_OP_LEGACY_SERVER_CONNECT); Is there any way of configuring stunnel to clear this option? If this is the wrong approach, how can I prevent stunnel connecting to unpatched servers? Thank you for your assistance and look forward to your response. John Simner [Unify: Harmonize your enterprise] John Simner BSc(Hons) MSc CEng. MIET Software Engineer, Devices Development Unify Enterprise Communications Ltd. Tel.: +44 (1908) 817378 (One Number Service) Email: john.simner(a)unify.com <mailto:[email protected]> www.unify.co.uk<http://www.unify.co.uk/> Follow us: [Social_media_icons] <http://www.unify.com/social-media> Unify Enterprise Communications Limited. Registered Office: Brickhill Street, Willen Lake, Milton Keynes, MK15 0DJ Registered No: 5903714, England. This email contains confidential information and is for the exclusive use of the addressee. If you are not the addressee then any distribution, copying, or use of this email is prohibited. If received in error, please advise the sender and delete immediately. We accept no liability for any loss or damage suffered by any person arising from use of this email.

1 0

Re: [stunnel-users] Trouble wrapping samba SWAT...
by Ludolf Holzheid 17 Jun '14

17 Jun '14

On Mon, 2014-06-16 12:53:36 +0200, Marco Gaiarin wrote: > > [..] > > and in /etc/stunnel/swat.conf.inetd: > > cert = /etc/ssl/certs/LNFFVGNobel.pem > key = /etc/ssl/private/LNFFVGNobel.pem > CAfile = /etc/ssl/certs/LNFFVG.pem > > service = swat > exec = /usr/sbin/swat > execargs = swat -P > > [..] > > the only thing i suppose is that for some reason stunnel4, run by root > in inetd, then switch to an unprivileged user before running swat, > preventing access to /var/lib/samba/secrets.tdb . Marco, I don't think stunnel changes the user ID without a 'setuid = ' statement in the configuration file (as it does not know which user ID to switch to). Are you sure, swat isn't changing the user ID? Does it work without being wrapped by stunnel? Ludolf -- Bihl+Wiedemann GmbH Floßwörthstraße 41 68199 Mannheim, Germany Tel: +49 621 33996-0 Fax: +49 621 3392239 mailto:[email protected] http://www.bihl-wiedemann.de Sitz der Gesellschaft: Mannheim Geschäftsführer: Jochen Bihl, Bernhard Wiedemann Amtsgericht Mannheim, HRB 5796

2 1