- stunnel-users - stunnel.org

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 26 Oct '11

26 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 25 Oct '11

25 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

stunnel 4.45 released
by Michal Trojnara 24 Oct '11

24 Oct '11

Dear Users, I have released version 4.45 of stunnel. The ChangeLog entry: Version 4.45, 2011.10.24, urgency: LOW: * New features - "protocol = proxy" support to send original client IP address to haproxy: http://haproxy.1wt.eu/download/1.5/doc/proxy-protocol.txt This requires accept-proxy bind option of haproxy 1.5-dev3 or later. - Added Win32 configuration reload without a valid configuration loaded. - Added compatibility with LTS OpenSSL versions 0.9.6 and 0.9.7. Some features are only available in OpenSSL 1.0.0 and later. * Performance optimizations - Use SSL_MODE_RELEASE_BUFFERS if supported by the OpenSSL library. - Libwrap helper processes are no longer started if libwrap is disabled in all sections of the configuration file. * Internal improvements - Protocol negotiation framework was rewritten to support additional code to be executed after SSL_accept()/SSL_connect(). - Handling of memory allocation errors was rewritten to gracefully terminate the process (thx to regenrecht for the idea). * Bugfixes - Fixed -l option handling in stunnel3 script (thx to Kai Gülzau). - Script to build default stunnel.pem was fixed (thx to Sebastian Kayser). - MinGW compilation script (mingw.mak) was fixed (thx to Jose Alf). - MSVC compilation script (vc.mak) was fixed. - A number of problems in WINSOCK error handling were fixed. Home page: http://www.stunnel.org/ Download: ftp://ftp.stunnel.org/stunnel/ SHA-256 hash for stunnel-4.45.tar.gz: cbce8279c1ba7a07bfefeb2e477f682bfd326519f8a7ed296e35210599898a2d Best regards, Mike

1 0

Check IP or Name of Client Or Server by Common Name
by Tigran Petrosyan 21 Oct '11

21 Oct '11

Hi all, I have made patch for stunnel-4.43. It helps you to switch on in the file of stunnell.conf new features, the option name is verify_peer. you can read more about it after patching, compiling and running the command "stunnel --help". The goal of this option to verify clients or servers "ip addreses or names of ip-addreses" with "Common name" of certificate. This option is very flexible and usable. It's possible to switch it of or use it as in field of global options and in service-level options. verify_peer = client_name | client_ip | remote_name | remote_ip -- Tigran Petrosyan

1 0

Attempting to debug slow stunnel connections
by Lamont Lucas 21 Oct '11

21 Oct '11

Hello stunnel-users, I've recently setup stunnel in front of haproxy to handle SSL connections. While it worked fine in testing, my simplistic benchmarks showed it unable to do more than 9 req/s, and as we turned some production traffic on, it appears that threads and connections quickly pile up and eventually timing out. I assume I've made some error in configuration, or there is something odd with my setup, as it appears stunnel has been benchmarked and performs well beyond what we're attempting here. I've read the FAQ and as much from the mailing list archives as I thought applicable, and I was unable to see any red flags or errors similar to what I'm seeing. If you don't mind, I'd like some help debugging the issue or pointers as to what else I could do to debug the issue. I've included details about my compile and configuration as well as the edited startup section from the debug (7) log. I compiled stunnel 4.44 with ./configure --disable-ipv6 --disable-libwrap --disable-fips. It's running on a different box than where it was compiled, but both machines should be identical. openssl version -a OpenSSL 0.9.8e-fips-rhel5 01 Jul 2008 built on: Thu Sep 3 14:22:06 EDT 2009 platform: linux-x86_64 options: bn(64,64) md2(int) rc4(ptr,int) des(idx,cisc,16,int) blowfish(ptr2) compiler: gcc -fPIC -DOPENSSL_PIC -DZLIB -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -DKRB5_MIT -I/usr/kerberos/include -DL_ENDIAN -DTERMIO -WallM OPENSSLDIR: "/etc/pki/tls" engines: dynamic stunnel.4.44 -version stunnel 4.44 on x86_64-unknown-linux-gnu platform Compiled/running with OpenSSL 0.9.8e-fips-rhel5 01 Jul 2008 Threading:PTHREAD SSL:ENGINE Auth:none Sockets:POLL,IPv4 Global options: debug = daemon.notice pid = /usr/local/var/run/stunnel/stunnel.pid RNDbytes = 64 RNDfile = /dev/urandom RNDoverwrite = yes Service-level options: ciphers = ALL:!SSLv2:!aNULL:!EXP:!LOW:-MEDIUM:RC4:+HIGH curve = prime256v1 session = 300 seconds sslVersion = TLSv1 for client, all for server stack = 65536 bytes TIMEOUTbusy = 300 seconds TIMEOUTclose = 60 seconds TIMEOUTconnect = 10 seconds TIMEOUTidle = 43200 seconds verify = none Here's my configuration file: sslVersion = all ciphers = RC4-MD5:HIGH:!aNULL:!SSLv2 options = NO_SSLv2 setuid = root setgid = haproxy pid = /var/run/stunnel.pid #socket = l:TCP_NODELAY=1 #socket = r:TCP_NODELAY=1 output = /var/log/stunnel.log debug = 7 [XXX] CAfile = /etc/stunnel/ca_chain.crt cert = /etc/stunnel/XXX.crt key = /etc/stunnel/XXX.key accept = 443 connect = 127.0.0.1:81 #xforwardedfor = yes #TIMEOUTclose = 5 #TIMEOUTbusy = 2 #TIMEOUTconnect = 2 #TIMEOUTidle = 2 (I was previously running 4.32 with the xforwardedfor patch, but to eliminate potential issues I've upgraded to the latest version, running stock without the patch, hence the commented out xforwardedfor option) here's the startup: 2011.10.01 12:18:38 LOG7[21868:47602610340864]: No limit detected for the number of clients 2011.10.01 12:18:38 LOG7[21868:47602610340864]: signal_pipe: FD=3 allocated (non-blocking mode) 2011.10.01 12:18:38 LOG7[21868:47602610340864]: signal_pipe: FD=4 allocated (non-blocking mode) 2011.10.01 12:18:38 LOG5[21868:47602610340864]: stunnel 4.44 on x86_64-unknown-linux-gnu platform 2011.10.01 12:18:38 LOG5[21868:47602610340864]: Compiled/running with OpenSSL 0.9.8e-fips-rhel5 01 Jul 2008 2011.10.01 12:18:38 LOG5[21868:47602610340864]: Threading:PTHREAD SSL:ENGINE Auth:none Sockets:POLL,IPv4 2011.10.01 12:18:38 LOG5[21868:47602610340864]: Reading configuration from file /etc/stunnel/stunnel.conf 2011.10.01 12:18:38 LOG7[21868:47602610340864]: PRNG seeded successfully 2011.10.01 12:18:38 LOG6[21868:47602610340864]: Initializing SSL context for service XXX 2011.10.01 12:18:38 LOG4[21868:47602610340864]: Insecure file permissions on /etc/stunnel/XXX.key 2011.10.01 12:18:38 LOG7[21868:47602610340864]: Certificate: /etc/stunnel/XXX.crt 2011.10.01 12:18:38 LOG7[21868:47602610340864]: Certificate loaded 2011.10.01 12:18:38 LOG7[21868:47602610340864]: Key file: /etc/stunnel/XXX.key 2011.10.01 12:18:38 LOG7[21868:47602610340864]: Private key loaded 2011.10.01 12:18:38 LOG7[21868:47602610340864]: Could not load DH parameters from /etc/stunnel/XXX.crt 2011.10.01 12:18:38 LOG7[21868:47602610340864]: Using hardcoded DH parameters 2011.10.01 12:18:38 LOG7[21868:47602610340864]: DH initialized with 2048-bit key 2011.10.01 12:18:38 LOG7[21868:47602610340864]: SSL options set: 0x01000000 2011.10.01 12:18:38 LOG6[21868:47602610340864]: SSL context initialized 2011.10.01 12:18:38 LOG5[21868:47602610340864]: Configuration successful Later, I see logs more or less like this: 2011.10.01 12:41:44 LOG7[29902:1108293952]: str_stats: 0 block(s), 0 data byte(s), 0 control byte(s) 2011.10.01 12:41:43 LOG7[29902:1116580160]: Service XXX started 2011.10.01 12:41:44 LOG7[29902:1116580160]: Option TCP_NODELAY set on local socket 2011.10.01 12:41:44 LOG5[29902:1116580160]: Service XXX accepted connection from YYY1:50059 2011.10.01 12:41:44 LOG7[29902:1108363584]: SSL state (accept): SSLv3 write server done A 2011.10.01 12:41:43 LOG7[29902:47056920704000]: local socket: FD=184 allocated (non-blocking mode) 2011.10.01 12:41:44 LOG7[29902:1108363584]: SSL state (accept): SSLv3 flush data 2011.10.01 12:41:44 LOG7[29902:47056920704000]: Service XXX accepted FD=184 from YYY2:58131 2011.10.01 12:41:44 LOG3[29902:1108363584]: SSL_accept: Peer suddenly disconnected 2011.10.01 12:41:44 LOG7[29902:1108433216]: SSL state (accept): before/accept initialization 2011.10.01 12:41:44 LOG7[29902:47056920704000]: local socket: FD=11 allocated (non-blocking mode) 2011.10.01 12:41:44 LOG7[29902:47056920704000]: Service XXX accepted FD=11 from YYY3:49309 2011.10.01 12:41:44 LOG5[29902:1108363584]: Connection reset: 0 bytes sent to SSL, 0 bytes sent to socket 2011.10.01 12:41:44 LOG7[29902:1108363584]: Service XXX finished (173 left) I see the thread count steadily increase: # ps -eLf |grep stun |wc -l 513 later: # ps -eLf |grep stun |wc -l 1020 (the FD ulimit for this proces is only 1024 currently, but that does not appear to be the limiting factor yet) It's almost like stunnel is only processing one connection at a time to the local destination port, which causes stunnel to build up a pile of waiting connections and eventually they start timing out. I've verified with nc and some local tests that the 127.0.0.1:81 port is picking up connections even under load, so I don't believe the issue is on the haproxy side. The firewall is set to allow all localhost connections and the 443 ports are configured the same as the port 80 ports which do hundreds of reqs a second, further ruling out firewall issues. Is there any setting I'm missing that would or wouldn't allow stunnel to process connect calls in parallel? Is there any additional debug information I can provide? Thank you for your time.

2 1

"connect_blocking"
by Maroon Brinks 21 Oct '11

21 Oct '11

Hi Everyone, I was hoping you could help. I cannot for the life of me get my program to connect through stunnel to this ip address. It appears to connect to stunnel just fine, however I constantly recieve: "connect_blocking" and I've found it very very hard to find information on the internet about this error. Here is the log output below followed by my configuration file: ####LOG#### 2011.10.19 09:49:56 LOG7[28234:139956427736816]: local socket: FD=8 allocated (non-blocking mode) 2011.10.19 09:49:56 LOG7[28234:139956427736816]: Service bgcssl accepted FD=8 from 127.0.0.1:58178 2011.10.19 09:49:56 LOG7[28234:139956427839760]: Service bgcssl started 2011.10.19 09:49:56 LOG7[28234:139956427839760]: Option TCP_NODELAY set on local socket 2011.10.19 09:49:56 LOG5[28234:139956427839760]: Service bgcssl accepted connection from 127.0.0.1:58178 2011.10.19 09:49:56 LOG7[28234:139956427839760]: remote socket: FD=9 allocated (non-blocking mode) 2011.10.19 09:49:56 LOG6[28234:139956427839760]: connect_blocking: connecting 148.106.128.90:7631 2011.10.19 09:49:56 LOG7[28234:139956427839760]: connect_blocking: s_poll_wait 148.106.128.90:7631: waiting 10 seconds 2011.10.19 09:50:06 LOG3[28234:139956427839760]: connect_blocking: s_poll_wait 148.106.128.90:7631: TIMEOUTconnect exceeded 2011.10.19 09:50:06 LOG5[28234:139956427839760]: Connection reset: 0 bytes sent to SSL, 0 bytes sent to socket 2011.10.19 09:50:06 LOG7[28234:139956427839760]: Service bgcssl finished (0 left) 2011.10.19 09:50:06 LOG7[28234:139956427839760]: str_stats: 0 block(s), 0 data byte(s), 0 control byte(s) ####CONFIG FILE#### ; stunnel.conf pid = /home/stunnel/bin/stunnel.pid ;setuid = nobody ;setgid = nobody foreground = yes sslVersion = TLSv1 service = stunnel client = yes debug = 7 output = stunnel.log [bgcssl] client = yes accept = 127.0.0.1:12347 connect = 148.106.128.90:7631 Any help would be greatly appreciated. Regards, Mark

2 1

Indirect CRL Support
by Sligar, Benjamin 21 Oct '11

21 Oct '11

I have been working, over the past few weeks, with one of my developers, attempting to support Indirect CRL's through OpenSSL/Stunnel. My initial attempts were to support direct CRL, which seems to work fine with the compile options I've listed below for both OpenSSL and Stunnel. ./config --prefix=/u/publish/dev/openssl/openssl-1.0.0d no-idea no-mdc2 no-rc5 no-md2 no-sse2 ./configure --prefix=/usr/local/stunnel-4.44/ --with-ssl=/usr/local/openssl-1.0.0d/ Reading through the FAQ and general documentation, I'm not finding much useful information on how to enable iCRL support. It may be a simple compile option I'm missing, or perhaps I just didn't find the correct page on the site/documentation, yet. If anyone has any useful information, or can point me in the right direction, the help would be greatly appreciated. I can provide configuration files and logs if it's of any use in this. Thank you in advance for any help you may be able to provide! My search continues.... ************************* Benjamin Sligar Manager, Development Support P: 703.453.8324 US_DEV_Support(a)tnsi.com ************************* This e-mail message is for the sole use of the intended recipient(s)and may contain confidential and privileged information of Transaction Network Services. Any unauthorised review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message.

2 1

NETBIOS over stunnel
by Ronald RiemVis 17 Oct '11

17 Oct '11

Dear all, Stunnel work with all kind of other connections on both side but can't get working the NETBIOS negotiation with the net use command. send like: net use q: \\10.0.0.1\name password /user:username does not work when use net use q: \\10.0.0.1\name /user:username I get the question about password.At the end also will fail Because an ISP blocked all traffic over port 139 and my friend want to attach my external LAN drive (my book live) I need to redirect ports including the netbios protocol. I want: from a local loopback network adapter with IP address 10.0.0.1 port 139 to an external adddres port 1000 This is the configuration on the site where the my book live is connected: client = yes [MyBook] accept = 10.56.10.100:1000 (is my local address) connect = 10.56.10.10:139 (address of the my book live device) On the other side is the coinfiguration: client = yes [MyBook] accept = 10.0.0.1:139 (loopback addapter address) connect = remote address:1000 (external address) What can I do more to let it work? Greetings, Ronald

2 1

default ciphers in stunnel 4.43 vs. stunnel 4.33
by Brian Peterson 14 Oct '11

14 Oct '11

Hello, I recently upgraded stunnel from 4.33 to 4.43 and immediately noticed problems with a particular client trying to connect to my servers. It appears that the client only supports SSLv2 (about which I will be talking to the client developers). In reviewing the stunnel release notes, I find that "!SSLv2" was first added to the default ciphers value in 4.37 and was retained in the default ciphers value in 4.40. What I am trying to find out at this point is what the default cipher list would have been under 4.33. I have grep'd the sources and found STUNNEL_CIPHER_LIST in options.c for 4.43, but there is no corresponding default ciphers config in 4.33. It *appears* that 4.33 is inheriting its default ciphers from whatever the installed OpenSSL uses by default. Is that correct? If I set ciphers to "ALL" under 4.43 would the running stunnel be using the same cipher list as the 4.33 build we were running previously? Thanks, Brian P.S. - No need to discuss the wisdom of our cipher list at the moment... I just want to get this client functioning and then worry about The Right Thing To Do.

1 0