March 2011 - stunnel-users

stunnel in DMZ : accept=22 / connect=other.server.net:22 - gets stuck! - need help!
by Bernhard.Baeumle＠mt.com 17 Mar '11

17 Mar '11

Hi I use stunnel on a DMZ server for tunnelling/forwarding/proxying... (whatever term is correct). The situation is as follows: Hardware : External PC <==> DMZ server <==> company-internal server Operational : https://xxx.yy.zz (443) <==> (443) stunnel (80) <==> (80) SVN Server listening on port 80 NEW/NEED HELP : plink (22) <==> (22) stunnel (22) <==> (22) sshd listening on port 22 stunnel.conf (on the DMZ server) looks like this: cert = my_tunnel.pem key = my_tunnel.pem socket = l:TCP_NODELAY=1 socket = r:TCP_NODELAY=1 socket = a:SO_REUSEADDR=0 debug = 7 output = C:\Program Files (x86)\stunnel\stunnel.log ;client = yes [forward_443_to_80] accept = 443 connect = my.company-server.net:80 [forward_22] accept = 22 connect = my.company-server.net:22 NOTE: Forwarding 443 to my.company-server.net:80 => WORKS FINE! NOW I try SSH with my PC connected to the company's network (without hopping at the DMZ): "plink -A -v -l username -i cert_file -P 22 dmz-server-name.net" => THIS WORKS FINE! NOW I try SSH with my PC from external network (which needs hopping at the DMZ): "plink -A -v -l username -i cert_file -P 22 dmz-server-name.net" Firewalls and ports seem to be open. The stunnel.log looks like this: <<starting stunnel service>> 2011.03.17 15:27:09 LOG5[4772:3852]: Reading configuration from file stunnel.conf 2011.03.17 15:27:09 LOG7[4772:3852]: Snagged 64 random bytes from C:/.rnd 2011.03.17 15:27:09 LOG7[4772:3852]: Wrote 1024 new random bytes to C:/.rnd 2011.03.17 15:27:09 LOG7[4772:3852]: PRNG seeded successfully 2011.03.17 15:27:09 LOG6[4772:3852]: Could not load DH parameters from my_tunnel.pem 2011.03.17 15:27:09 LOG7[4772:3852]: ECDH initialized 2011.03.17 15:27:09 LOG7[4772:3852]: Certificate: my_tunnel.pem 2011.03.17 15:27:09 LOG7[4772:3852]: Certificate loaded 2011.03.17 15:27:09 LOG7[4772:3852]: Key file: my_tunnel.pem 2011.03.17 15:27:09 LOG7[4772:3852]: Private key loaded 2011.03.17 15:27:09 LOG7[4772:3852]: SSL context initialized for service forward_443_to_80 2011.03.17 15:27:09 LOG6[4772:3852]: Could not load DH parameters from my_tunnel.pem 2011.03.17 15:27:09 LOG7[4772:3852]: ECDH initialized 2011.03.17 15:27:09 LOG7[4772:3852]: Certificate: my_tunnel.pem 2011.03.17 15:27:09 LOG7[4772:3852]: Certificate loaded 2011.03.17 15:27:09 LOG7[4772:3852]: Key file: my_tunnel.pem 2011.03.17 15:27:09 LOG7[4772:3852]: Private key loaded 2011.03.17 15:27:09 LOG7[4772:3852]: SSL context initialized for service forward_22 2011.03.17 15:27:09 LOG5[4772:3852]: Configuration successful 2011.03.17 15:27:09 LOG5[4772:3852]: No limit detected for the number of clients 2011.03.17 15:27:09 LOG7[4772:3852]: accept socket: FD=168 allocated (non-blocking mode) 2011.03.17 15:27:09 LOG7[4772:3852]: Option SO_REUSEADDR set on accept socket 2011.03.17 15:27:09 LOG7[4772:3852]: Service forward_443_to_80 bound to 0.0.0.0:443 2011.03.17 15:27:09 LOG7[4772:3852]: Service forward_443_to_80 opened FD=168 2011.03.17 15:27:09 LOG7[4772:3852]: accept socket: FD=280 allocated (non-blocking mode) 2011.03.17 15:27:09 LOG7[4772:3852]: Option SO_REUSEADDR set on accept socket 2011.03.17 15:27:09 LOG7[4772:3852]: Service forward_22 bound to 0.0.0.0:22 2011.03.17 15:27:09 LOG7[4772:3852]: Service forward_22 opened FD=280 2011.03.17 15:27:09 LOG5[4772:3852]: stunnel 4.35 on x86-pc-mingw32-gnu with OpenSSL 1.0.0c 2 Dec 2010 2011.03.17 15:27:09 LOG5[4772:3852]: Threading:WIN32 SSL:ENGINE Sockets:SELECT,IPv6 <<calling plink...>> 2011.03.17 15:27:26 LOG7[4772:4208]: local socket: FD=320 allocated (non-blocking mode) 2011.03.17 15:27:26 LOG7[4772:4208]: Service forward_22 accepted FD=320 from 123.4.5.6:2950 2011.03.17 15:27:26 LOG7[4772:4208]: Creating a new thread 2011.03.17 15:27:26 LOG7[4772:4208]: New thread created 2011.03.17 15:27:26 LOG7[4772:4756]: Service forward_22 started 2011.03.17 15:27:26 LOG7[4772:4756]: Option TCP_NODELAY set on local socket 2011.03.17 15:27:26 LOG5[4772:4756]: Service forward_22 accepted connection from 123.4.5.6:2950 2011.03.17 15:27:26 LOG7[4772:4756]: SSL state (accept): before/accept initialization <<and here it gets stuck!!!!!!!>> plink says: Looking up host "dmz-server-name.net" Connecting to 123.12.1.1 port 22 <<and here it gets stuck!!!!!!!>> PLEASE HELP!!!

2 1

SSL_read: 140D5042: error:140D5042:SSL routines:SSL3_CTRL:called a function you should not call
by Julian Ramirez 16 Mar '11

16 Mar '11

Hello all, I am using stunnel in order to send encrypted http request/response messages to an external system called Tradeweb. Our python program sends the message to stunnel and stunnel sends it to Tradeweb through a proxy. My version of stunnel is the following stunnel 4.35 on sparc-sun-solaris2.10 with OpenSSL 0.9.8r 8 Feb 2011 and it has been installed in a Solaris 10 operating system. My configuration file looks like this CAfile=/home/aps/tfk/stunnel/etc/stunnel/tradeweb_ca.cer client=yes verify=2 debug=7 output=stunnel.log [TradeXpress] # Port on which STUNNEL listens for local connections accept=stunnelserveripaddress:17000 # Destination address and port of TW data-center libwrap=no connect=proxyipaddress:80 protocol=connect protocolHost=tradewebipaddress:443 I have a python program that sends a http post message to stunnel. When I send the message I can see the following in the log (see below) The message gets to the other end (tradeweb system), but it looks like the encryption does not work properly. The relevant lines of the log are (see full log below) 2011.03.14 18:24:19 LOG7[6089:2]: SSL alert (write): warning: no certificate 2011.03.14 18:29:25 LOG3[6089:2]: SSL_read: 140D5042: error:140D5042:SSL routines:SSL3_CTRL:called a function you should not call 2011.03.14 18:29:25 LOG5[6089:2]: Connection reset: 521 bytes sent to SSL, 0 bytes sent to socket Do you know what is the problem? Thank you, Julian 2011.03.14 18:23:54 LOG5[6083:1]: Reading configuration from file stunnel.conf 2011.03.14 18:23:54 LOG7[6083:1]: Snagged 64 random bytes from /home/usr/vptfk/.rnd 2011.03.14 18:23:54 LOG7[6083:1]: Wrote 1024 new random bytes to /home/usr/vptfk/.rnd 2011.03.14 18:23:54 LOG7[6083:1]: PRNG seeded successfully 2011.03.14 18:23:54 LOG7[6083:1]: Loaded verify certificates from /home/aps/tfk/stunnel/etc/stunnel/tradeweb_ca.cer 2011.03.14 18:23:54 LOG7[6083:1]: Loaded /home/aps/tfk/stunnel/etc/stunnel/tradeweb_ca.cer revocation lookup file 2011.03.14 18:23:54 LOG7[6083:1]: SSL context initialized for service TradeXpress 2011.03.14 18:23:54 LOG5[6083:1]: Configuration successful 2011.03.14 18:23:54 LOG5[6083:1]: No limit detected for the number of clients 2011.03.14 18:23:54 LOG7[6083:1]: libwrap_init: FD=5 allocated (blocking mode) 2011.03.14 18:23:54 LOG7[6083:1]: libwrap_init: FD=4 allocated (blocking mode) 2011.03.14 18:23:54 LOG7[6083:1]: libwrap_init: FD=6 allocated (blocking mode) 2011.03.14 18:23:54 LOG7[6083:1]: libwrap_init: FD=4 allocated (blocking mode) 2011.03.14 18:23:54 LOG7[6083:1]: libwrap_init: FD=7 allocated (blocking mode) 2011.03.14 18:23:54 LOG7[6083:1]: libwrap_init: FD=4 allocated (blocking mode) 2011.03.14 18:23:54 LOG7[6083:1]: libwrap_init: FD=8 allocated (blocking mode) 2011.03.14 18:23:54 LOG7[6083:1]: libwrap_init: FD=4 allocated (blocking mode) 2011.03.14 18:23:54 LOG7[6083:1]: libwrap_init: FD=9 allocated (blocking mode) 2011.03.14 18:23:54 LOG7[6083:1]: libwrap_init: FD=4 allocated (blocking mode) 2011.03.14 18:23:54 LOG7[6083:1]: signal_pipe: FD=4 allocated (blocking mode) 2011.03.14 18:23:54 LOG7[6083:1]: signal_pipe: FD=10 allocated (blocking mode) 2011.03.14 18:23:54 LOG7[6083:1]: accept socket: FD=11 allocated (non-blocking mode) 2011.03.14 18:23:54 LOG7[6083:1]: Option SO_REUSEADDR set on accept socket 2011.03.14 18:23:54 LOG7[6083:1]: Service TradeXpress bound to 0.0.0.0:17000 2011.03.14 18:23:54 LOG7[6083:1]: Service TradeXpress opened FD=11 2011.03.14 18:23:54 LOG7[6089:1]: Created pid file /home/aps/tfk/stunnel/var/run/stunnel/stunnel.pid 2011.03.14 18:23:54 LOG5[6089:1]: stunnel 4.35 on sparc-sun-solaris2.10 with OpenSSL 0.9.8r 8 Feb 2011 2011.03.14 18:23:54 LOG5[6089:1]: Threading:PTHREAD SSL:ENGINE Sockets:POLL,IPv6 Auth:LIBWRAP 2011.03.14 18:23:54 LOG7[6089:1]: Dispatching signals from the signal pipe 2011.03.14 18:23:54 LOG7[6089:1]: Signal pipe is empty 2011.03.14 18:24:19 LOG7[6089:1]: local socket: FD=0 allocated (non-blocking mode) 2011.03.14 18:24:19 LOG7[6089:1]: Service TradeXpress accepted FD=0 from stunnelserveripaddress:61449 2011.03.14 18:24:19 LOG7[6089:2]: Service TradeXpress started 2011.03.14 18:24:19 LOG5[6089:2]: Service TradeXpress accepted connection from stunnelserveripaddress:61449 2011.03.14 18:24:19 LOG7[6089:2]: remote socket: FD=1 allocated (non-blocking mode) 2011.03.14 18:24:19 LOG6[6089:2]: connect_blocking: connecting proxyipaddress:80 2011.03.14 18:24:19 LOG7[6089:2]: connect_blocking: s_poll_wait proxyipaddress:80: waiting 10 seconds 2011.03.14 18:24:19 LOG5[6089:2]: connect_blocking: connected proxyipaddress:80 2011.03.14 18:24:19 LOG5[6089:2]: Service TradeXpress connected remote server from stunnelserveripaddress:61450 2011.03.14 18:24:19 LOG7[6089:2]: Remote FD=1 initialized 2011.03.14 18:24:19 LOG5[6089:2]: Negotiations for connect (client side) started 2011.03.14 18:24:19 LOG7[6089:2]: -> CONNECT tradewebipaddress:443 HTTP/1.1 2011.03.14 18:24:19 LOG7[6089:2]: -> Host: tradewebipaddress:443 2011.03.14 18:24:19 LOG7[6089:2]: -> 2011.03.14 18:24:19 LOG7[6089:2]: <- HTTP/1.1 200 Connection established 2011.03.14 18:24:19 LOG6[6089:2]: CONNECT request accepted 2011.03.14 18:24:19 LOG7[6089:2]: <- 2011.03.14 18:24:19 LOG5[6089:2]: Protocol negotiations succeeded 2011.03.14 18:24:19 LOG7[6089:2]: SSL state (connect): before/connect initialization 2011.03.14 18:24:19 LOG7[6089:2]: SSL state (connect): SSLv3 write client hello A 2011.03.14 18:24:19 LOG7[6089:2]: SSL state (connect): SSLv3 read server hello A 2011.03.14 18:24:19 LOG7[6089:2]: Starting certificate verification: depth=1, /C=US/ST=New York/L=New York/O=TradeWeb LLC - The Online Bond Markets/OU=Network Administration/CN=TradeWeb LLC - The Online Bond Markets/emailAddress=bruce.mackinnon(a)tradeweb.c 2011.03.14 18:24:19 LOG5[6089:2]: Certificate accepted: depth=1, /C=US/ST=New York/L=New York/O=TradeWeb LLC - The Online Bond Markets/OU=Network Administration/CN=TradeWeb LLC - The Online Bond Markets/emailAddress=bruce.mackinnon(a)tradeweb.com 2011.03.14 18:24:19 LOG7[6089:2]: Starting certificate verification: depth=0, /C=US/ST=New Jersey/L=Jersey City/O=TradeWeb LLC - The Online Bond Markets/OU=STP Production/CN=62.189.50.234 2011.03.14 18:24:19 LOG5[6089:2]: Certificate accepted: depth=0, /C=US/ST=New Jersey/L=Jersey City/O=TradeWeb LLC - The Online Bond Markets/OU=STP Production/CN=62.189.50.234 2011.03.14 18:24:19 LOG7[6089:2]: SSL state (connect): SSLv3 read server certificate A 2011.03.14 18:24:19 LOG7[6089:2]: SSL state (connect): SSLv3 read server certificate request A 2011.03.14 18:24:19 LOG7[6089:2]: SSL state (connect): SSLv3 read server done A 2011.03.14 18:24:19 LOG7[6089:2]: SSL alert (write): warning: no certificate 2011.03.14 18:24:19 LOG7[6089:2]: SSL state (connect): SSLv3 write client certificate A 2011.03.14 18:24:19 LOG7[6089:2]: SSL state (connect): SSLv3 write client key exchange A 2011.03.14 18:24:19 LOG7[6089:2]: SSL state (connect): SSLv3 write change cipher spec A 2011.03.14 18:24:19 LOG7[6089:2]: SSL state (connect): SSLv3 write finished A 2011.03.14 18:24:19 LOG7[6089:2]: SSL state (connect): SSLv3 flush data 2011.03.14 18:24:19 LOG7[6089:2]: SSL state (connect): SSLv3 read finished A 2011.03.14 18:24:19 LOG7[6089:2]: 0 items in the session cache 2011.03.14 18:24:19 LOG7[6089:2]: 1 client connects (SSL_connect()) 2011.03.14 18:24:19 LOG7[6089:2]: 1 client connects that finished 2011.03.14 18:24:19 LOG7[6089:2]: 0 client renegotiations requested 2011.03.14 18:24:19 LOG7[6089:2]: 0 server connects (SSL_accept()) 2011.03.14 18:24:19 LOG7[6089:2]: 0 server connects that finished 2011.03.14 18:24:19 LOG7[6089:2]: 0 server renegotiations requested 2011.03.14 18:24:19 LOG7[6089:2]: 0 session cache hits 2011.03.14 18:24:19 LOG7[6089:2]: 0 external session cache hits 2011.03.14 18:24:19 LOG7[6089:2]: 0 session cache misses 2011.03.14 18:24:19 LOG7[6089:2]: 0 session cache timeouts 2011.03.14 18:24:19 LOG6[6089:2]: SSL connected: new session negotiated 2011.03.14 18:24:19 LOG6[6089:2]: Negotiated ciphers: AES256-SHA SSLv3 Kx=RSA Au=RSA Enc=AES(256) Mac=SHA1 2011.03.14 18:29:25 LOG3[6089:2]: SSL_read: 140D5042: error:140D5042:SSL routines:SSL3_CTRL:called a function you should not call 2011.03.14 18:29:25 LOG5[6089:2]: Connection reset: 521 bytes sent to SSL, 0 bytes sent to socket 2011.03.14 18:29:25 LOG7[6089:2]: Service TradeXpress finished (0 left) RAMIREZ Julián Technical Consultant Wall Street Systems <http://www.wallstreetsystems.com/> - Empowering Treasury, Trading and Settlement

1 0

Stunnel configuration for multiple domains on single IP
by Amol 11 Mar '11

11 Mar '11

I was trying to configure stunnel to work for multiple domains on the same IP address, just wanted to know how to configure stunnel to listen on different ports? has anyone done it yet? [https-lo] cert=/etc/stunnel/ssl/group-cert.pem key = /etc/stunnel/ssl/lo.key accept=x.x.x.x:443 connect=x.xxx.xx.11:8000 TIMEOUTclose=0 xforwardedfor=yes [https-lo2] cert=/etc/stunnel/ssl/group2-cert.pem key = /etc/stunnel/ssl/lo2.key accept=xx.xx.xx.xx:444 connect=x.xxx.xx.11:80 TIMEOUTclose=0 xforwardedfor=yes but i still get this error when i access the second domain (lo2) (Error code: ssl_error_bad_cert_domain)

1 1

Periodic stunnel 4.34 core dumps on AIX 5.3
by Allex, Paul M (USA E D EA STS) 11 Mar '11

11 Mar '11

Hello, I have noticed that stunnel will periodically core dump on AIX 5.3. My configuration: stunnel 4.34 AIX 5.3 OpenSSL 0.9.8m After some initial investigation, I did find the following post about stunnel core dumps on AIX 5.3: http://www.stunnel.org/pipermail/stunnel-users/2007-April/001528.html Some of the core dumps were definitely due to this issue, so I rebuilt stunnel using the steps outlined in the post. Now I do not see the stack overflow core dumps, however I am still seeing other cores. These cores have little to no valuable information in them, so I do not have a lot to go off of. The one thing I have noticed is that stunnel seems to be consuming more and more memory over time. I set up several tests to see what would be causing this. Tests: 1. Send large amounts of data through stunnel using a simple client and server. This seemed to have no affect on the long term memory usage of stunnel. 2. Repeatedly create and drop connections to stunnel. For this I wrote a short script that simply creates a connection to stunnel using telnet in a a tight loop. I did not start anything for the stunnel instance to connect to, so telnet would create a connection and get it closed immediately. telnet --> stunnel --> nothing The process started with a size of 836 KB and seems to increase by about .1 to .2 KB per connection. $ count=1; while true; do tn localhost 10500; echo $count; count=$(( count + 1 )); done Trying... Escape character is '^T'. Connection closed. 1 ... Trying... Connected to loopback. Escape character is '^T'. Connection closed. 15475 Trying... Connected to loopback. Escape character is '^T'. Connection closed. 15476 Trying... Connected to loopback. Escape character is '^T'. Connection closed. 15477 $ monitor_process test_stunnel Size: 836 ... Size: 2556 Size: 2564 Size: 2564 Size: 2564 Size: 2568 Size: 2572 Size: 2572 Size: 2592 I have not dug into the code yet, so I suppose that will be my next task. If anyone has any ideas or suggestions on what else to look at, I would really appreciate it. Thanks, Paul Allex

2 2

Re: [stunnel-users] Periodic stunnel 4.34 core dumps on AIX 5.3
by Allex, Paul M (USA E D EA STS) 10 Mar '11

10 Mar '11

I let the connection/memory script run over night and it appears that stunnel's memory usage has plateaued at 131,432 KB. I'm not sure how many connections had occurred when the memory usage leveled of, but currently there have been over 1.7 million connections to stunnel. I guess for now, please don't waste any time on this issue until I gather more information. Paul Allex

1 0

error:14094412:SSL routines:SSL3_READ_BYTES:sslv3
by don-stunnel-zyx＠isis.cs3-inc.com 04 Mar '11

04 Mar '11

stuff in [brackets] is replaced to protect the innocent stunnel.conf: ================ debug=5 output=/root/stunnel.log cert=/etc/pki/tls/certs/[certfile] CAfile=/etc/pki/tls/certs/[bundle].crt key=/etc/pki/tls/private/[private-key].key [debug] accept=801 client=yes connect=[...].com:443 ================ I then connect to localhost:801 and stunnel.log contains: ================ 2011.02.28 19:18:45 LOG5[20520:3086252944]: debug connected from 127.0.0.1:38472 2011.02.28 19:18:46 LOG3[20520:3086252944]: SSL_connect: 14094412: error:14094412:SSL routines:SSL3_READ_BYTES:sslv3 alert bad certificate 2011.02.28 19:18:46 LOG5[20520:3086252944]: Connection reset: 0 bytes sent to SSL, 0 bytes sent to socket ================ I don't see anything wrong with the cert or private key - the following demo shows that at least openssl is happy with them: ================ echo "hello there" | openssl rsautl -certin -inkey /etc/pki/tls/certs/[certfile] -encrypt |openssl rsautl -inkey /etc/pki/tls/private/[private-key].key -decrypt hello there I've captured the packets sent between stunnel and the server and wireshark shows (at ssl level) client SSLv3 Client Hello server SSLv3 Server Hello, Certificate, Certificate Request, Server Hello Done client SSLv3 Certificate, Client Key Exchange, Certificate Verify, Change Cipher Spec, Encrypted Handshake Message server SSLv3 Alert (Level: Fatal, Description: Bad Certificate) followed by TCP resets So the server is complaining about my certificate. This is certainly not what I would have guessed the message in the log meant. It looks like an error from stunnel. So is it an error from stunnel or is it stunnel reporting a complaint from the server? And if the latter, what exactly did the server send? The entire message starting with error? or starting with 14094412? or what? Could this mean that the server doesn't understand the certificate (cause it's a 2K certificate instead of 1K?) or could it mean that the server doesn't like it for some other reason?

2 2

curl: (35) error:14094412:SSL routines:SSL3_READ_BYTES:sslv3
by don-stunnel-zyx＠isis.cs3-inc.com 01 Mar '11

01 Mar '11

Here's my command curl -E /root/key-cert https://ewsg-cert.prudent... and the result: curl: (35) error:14094412:SSL routines:SSL3_READ_BYTES:sslv3 alert bad certificate This seems weird to me: Note that this certificate is the private key and the private certificate concatenated! I assume the private certificate is just the certificate. In any case my file key-cert looks like -----BEGIN RSA PRIVATE KEY----- ... -----END RSA PRIVATE KEY----- -----BEGIN CERTIFICATE----- ... -----END CERTIFICATE----- What does the error above mean and what could I possibly be doing wrong to cause it?

1 1

forcing my untangle server to scan my https traffic
by Bing H Bang 01 Mar '11

01 Mar '11

I'm so close to making this work, I can taste it. I also need some suggestions on how to fix the last hurdle. My setup 10.0.0.10 ip of my webserver 24.159.165.122 static ip of my untangle server (router mode) untangle server port forwards 443 to 10.0.0.10:10443 80 to 10.0.0.10:80 (web server only listens on 443) stunnel config file on the web server [https-terminate] client = no cert = /var/lib/stroot/cypherdog.com.pem accept = 10.0.0.10:10443 connect = 24.159.165.122:80 [https-re-engage] client = yes accept = 10.0.0.10:80 connect = 10.0.0.10:443 What I'm trying to do is accept https traffic, decrypt it, pass it through untangle, then encrypt it back as it gets delivered to the https port of the web server. This setup works in that I can point my browser at the https port of my untangle server and the web pages work properly. What doesn't work is the untangle server shows no scanning activity when I access the web pages. I think the path webserver->untangle->webserver does not trigger the scanning in untangle because the traffic it sees is from an internal ip going to the same internal ip. Is there a way to fix this, anyone?

3 3