February 2009 - stunnel-users

Re: [stunnel-users] stunnel tls wrapper/proxy for xmpp
by C.J. Adams-Collier 04 Feb '09

04 Feb '09

On Mon, Feb 02, 2009 at 02:20:18PM -0800, Brian Hatch wrote: > Roughly around 2009-02-02 13:31 -0800, C.J. Adams-Collier broached: > > > I'm new here, and I didn't see anything relating to this after a quick > > glance at the archives. I'd like to start a stunnel connection > > connected to the google talk server and then connect finch up to that > > so that I can tap the clear xmpp session using tcpdump. Can one of > > you help me? > > 5222 requires starttls for xmpp, which stunnel doesn't support. > > 5223 is wrapped ssl and would work for you. Thanks Brian, That almost works, too! I think google only does TLS (5222) though. 23:01:03.594856 IP colliertech.org.35052 > od-in-f83.google.com.5223: S 2704797155:2704797155(0) win 5840 <mss 1460,sackOK,timestamp 133784958 0,nop,wscale 1> 23:01:06.591987 IP colliertech.org.35052 > od-in-f83.google.com.5223: S 2704797155:2704797155(0) win 5840 <mss 1460,sackOK,timestamp 133785708 0,nop,wscale 1> Was there a silent "yet" at the end of your "doesn't support" comment above? :) Do you need beta testers for this new feature? Cheers, C.J. > > -- > Brian Hatch Error 23 occurred when > Systems and attempting to report > Security Engineer error 23. > http://www.ifokr.org/bri/ > > Every message PGP signed

4 7

Error message vista
by Reinier van der Gugten 04 Feb '09

04 Feb '09

Hi, I use Stunnel for some of my customers. However I tried it myself (after a while, and after a reinstall of windows) and I get this error. Can anyone tell me how to get it to work again? I get the same error when I run it as administrator, or when I change the port from 443 to 4430. 2009.02.04 13:54:04 LOG7[2828:5668]: Snagged 64 random bytes from C:/.rnd 2009.02.04 13:54:04 LOG7[2828:5668]: Wrote 1024 new random bytes to C:/.rnd 2009.02.04 13:54:04 LOG7[2828:5668]: RAND_status claims sufficient entropy for the PRNG 2009.02.04 13:54:04 LOG7[2828:5668]: PRNG seeded successfully 2009.02.04 13:54:04 LOG7[2828:5668]: Certificate: stunnel.pem 2009.02.04 13:54:04 LOG7[2828:5668]: Certificate loaded 2009.02.04 13:54:04 LOG7[2828:5668]: Key file: stunnel.pem 2009.02.04 13:54:04 LOG7[2828:5668]: Private key loaded 2009.02.04 13:54:04 LOG7[2828:5668]: SSL context initialized for service SQLServer 2009.02.04 13:54:04 LOG5[2828:5668]: stunnel 4.26 on x86-pc-mingw32-gnu with OpenSSL 0.9.8i 15 Sep 2008 2009.02.04 13:54:04 LOG5[2828:5668]: Threading:WIN32 SSL:ENGINE Sockets:SELECT,IPv6 2009.02.04 13:54:04 LOG5[2828:5672]: No limit detected for the number of clients 2009.02.04 13:54:04 LOG7[2828:5672]: FD 224 in non-blocking mode 2009.02.04 13:54:04 LOG7[2828:5672]: SO_REUSEADDR option set on accept socket 2009.02.04 13:54:04 LOG3[2828:5672]: Error binding SQLServer to 127.0.0.1:31433 2009.02.04 13:54:04 LOG3[2828:5672]: bind: Permission denied (WSAEACCES) (10013) 2009.02.04 13:54:04 LOG3[2828:5672]: Server is down My stunnel.conf looks like this (actual IP address has been modified): ; Sample stunnel configuration file by Michal Trojnara 2002-2006 ; Some options used here may not be adequate for your particular configuration ; Certificate/key is needed in server mode and optional in client mode ; The default certificate is provided only for testing and should not ; be used in a production environment cert = stunnel.pem ;key = stunnel.pem ; Some performance tunings socket = l:TCP_NODELAY=1 socket = r:TCP_NODELAY=1 ; Authentication stuff ;verify = 2 ; Don't forget to c_rehash CApath ;CApath = certs ; It's often easier to use CAfile ;CAfile = certs.pem ; Don't forget to c_rehash CRLpath ;CRLpath = crls ; Alternatively you can use CRLfile ;CRLfile = crls.pem ; Some debugging stuff useful for troubleshooting debug = 7 ;output = stunnel.log ; Use it for client mode client = yes ; Service-level configuration [SQLServer] accept = 127.0.0.1:31433 connect = 85.15.135.121:443 ; In case of a proxy server, use: ;connect = 10.3.2.50:8080 ;protocol = connect ;protocolHost = 85.15.135.121:443

2 1

crl next update field functionality seems incorrect
by Steve Hoffman 04 Feb '09

04 Feb '09

Regarding this piece of code in verify.c: if(X509_cmp_current_time(next_update)<0) { s_log(LOG_WARNING, "Found CRL is expired - " "revoking all certificates until you get updated CRL"); X509_STORE_CTX_set_error(callback_ctx, X509_V_ERR_CRL_HAS_EXPIRED); X509_OBJECT_free_contents(&obj); return 0; /* reject connection */ } I don't believe this is correct functionality. The "next update" field is not an expiration of the CRL, but more of an indicator that you, as the holder of the CRL, should obtain a new one. Snippet from this link: http://www.netscape.ca/browser/netscape8/help/en/ssl_help.html#next_update About the "Next Update" Date The browser uses the CRLs it has available to check the validity of certificates issued by the corresponding CAs. If a certificate is listed as revoked, the browser won't accept it as evidence of identity. A CA typically publishes an updated CRL at regular intervals. Every CRL includes a date, specified in the Next Update field, by which the CA will publish the next update of that CRL. In general, if the date in the Next Update field is earlier than the current date, you should obtain the most recent version of the CRL. To view CRL information and set up automatic CRL updating, see Viewing and Managing CRLs. CAs are required to produce a new CRL by the Next Update date. However, the absence of the most recent CRL does not by itself invalidate a certificate. For this reason, if the most recent CRL is not available, a certificate may be validated even though the most recent CRL shows it as expired. Automatic CRL updating can help to avoid this situation. I'd like to suggest removing this check. Thanks, Steve

3 2

error compilation stunnel-4.11 for ARM9
by mailinglist 03 Feb '09

03 Feb '09

Did you ever receive a answer for your problem. Ic have the same problem now. checking for socklen_t... yes configure: **************************************** PTY device files checking for "/dev/ptmx"... configure: error: cannot check for file existence when cross compiling Thanks in advance for you help Ebse

1 0

stunnel tls wrapper/proxy for xmpp
by C.J. Adams-Collier 02 Feb '09

02 Feb '09

Hey all, I'm new here, and I didn't see anything relating to this after a quick glance at the archives. I'd like to start a stunnel connection connected to the google talk server and then connect finch up to that so that I can tap the clear xmpp session using tcpdump. Can one of you help me? Thanks in advance, C.J. cjac@sh0:~/stunnel$ cat stunnel.conf client = yes connect = el-in-f125.google.com:5222 foreground = yes pid = /tmp/stunnel4.pid debug = 7 cjac@sh0:~/stunnel$ stunnel-4.26/src/stunnel stunnel.conf 2009.02.02 21:31:13 LOG6[24798:140190659815120]: Unable to retrieve any random data from /home/cjac/.rnd 2009.02.02 21:31:13 LOG7[24798:140190659815120]: Wrote 0 new random bytes to /home/cjac/.rnd 2009.02.02 21:31:13 LOG7[24798:140190659815120]: RAND_status claims sufficient entropy for the PRNG 2009.02.02 21:31:13 LOG7[24798:140190659815120]: PRNG seeded successfully 2009.02.02 21:31:13 LOG7[24798:140190659815120]: SSL context initialized for service stunnel 2009.02.02 21:31:13 LOG5[24798:140190659815120]: stunnel 4.26 on x86_64-unknown-linux-gnu with OpenSSL 0.9.8c 05 Sep 2006 2009.02.02 21:31:13 LOG5[24798:140190659815120]: Threading:PTHREAD SSL:ENGINE Sockets:POLL,IPv6 2009.02.02 21:31:13 LOG7[24798:140190659815120]: stunnel started 2009.02.02 21:31:13 LOG7[24798:140190659815120]: FD 0 in non-blocking mode 2009.02.02 21:31:13 LOG7[24798:140190659815120]: FD 1 in non-blocking mode 2009.02.02 21:31:13 LOG7[24798:140190659815120]: FD 4 in non-blocking mode 2009.02.02 21:31:13 LOG7[24798:140190659815120]: stunnel connecting 209.85.163.125:5222 2009.02.02 21:31:13 LOG7[24798:140190659815120]: connect_wait: waiting 10 seconds 2009.02.02 21:31:14 LOG7[24798:140190659815120]: connect_wait: connected 2009.02.02 21:31:14 LOG5[24798:140190659815120]: stunnel connected remote server from 172.16.9.3:55967 2009.02.02 21:31:14 LOG7[24798:140190659815120]: Remote FD=4 initialized 2009.02.02 21:31:14 LOG7[24798:140190659815120]: SSL state (connect): before/connect initialization 2009.02.02 21:31:14 LOG7[24798:140190659815120]: SSL state (connect): SSLv3 write client hello A 2009.02.02 21:31:14 LOG7[24798:140190659815120]: SSL alert (write): fatal: handshake failure 2009.02.02 21:31:14 LOG3[24798:140190659815120]: SSL_connect: 1408F10B: error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version number 2009.02.02 21:31:14 LOG5[24798:140190659815120]: Connection reset: 0 bytes sent to SSL, 0 bytes sent to socket 2009.02.02 21:31:14 LOG7[24798:140190659815120]: stunnel finished (0 left)

2 1

Fwd: Stunnel & Zimbra
by Allen 02 Feb '09

02 Feb '09

Hi folks, I'm reposting this from my email address on file, because it was initially rejected (I think because I sent it from my main business address, which is not the address I have listed with this group. My apologies. ------------ I've been using stunnel with Zimbra, on OS X Sever since last year and it's been working well (SSL tunnels should be seen and not heard ;-). I upgraded Zimbra yesterday to a new version, that apparently was supposed to fix its instability running on the OS X platform. However, the upgrade wound up breaking the mail server's ability to send email. From Zimbra's web client, it appears like mail is getting sent (there's a little green sent mail box that pops up right after you click on the send button). Mail never arrives at the client end. I can still receive mail into the Zimbra account when I send to it from my business or personal email account. I provisoned and reloaded posffix, etc., and still can't receive mail on the other end. No stunnel settings have changed since before the upgrade. Here are the stunnel-related file outputs: ----------------------------------------------------------------- root# cat /opt/local/etc/stunnel/stunnel.conf client = yes foreground = no [smtps] accept = 5000 connect = server_name.x.y.com:465 (server name changed to protect the innocent ;-) ----------------------------------------------------------------- cat /opt/zimbra/conf/relay_password server_name.domain.com [email protected]:fakepassword --------------------------------------------- With the real usernames, password, domains, etc., those two (above) stunnel files worked perfectly well with stunnel, and sending mail was not a problem. That was --until I upgraded Zimbra. I realize that this is a stunnel forum and the Zimbra-related forum deals with all their issues. However, I'm wondering if somebody out there in stunnel land might have a light bulb going off regarding this issue. Perhaps there's something that I'm overlooking? Thanks! Allen

1 0

Identification Propagation patch using stunnel client certificates
by Christophe Nanteuil 02 Feb '09

02 Feb '09

Hello, NB : this patch is provided as alpha version : it handles only 1 request at a time for each administrative and ident servers. Why to use this patch ? This patch can be useful when : - you provide access to Internet via your stunnel server and when your legislation enforces you to keep logs of who connected where and when. In this case, you will have Squid logs filled with identification of stunnel clients in a very simple way : nothing to ask to the client as it uses automatically its certificate to fill in the identity fields. - you want to implement several profile access for your clients accessing your web proxy/server : as the proxy will ask ident request to stunnel, you can create filter groups to allow / denied access (with redirection to a page that you can customize) depending on stunnel answer : see filtergroups option of DansGuardian or acl options in squid. Patch to version : 4.26 Type : new feature Description : Identification Propagation using stunnel client certificates The patch proposes to extend the identification propagation provided by the directive 'EXEC=' to directive 'CONNECT=' when using client certificates. With EXEC directive, Subject name and Issuer Name of clients are put in environment variables, which allows the program to determine identity of the stunnel client. This patch adds an ident server functionality to stunnel, compliant with RFC 1413, to allow propagation of identification to remote hosts specified by the service directive 'CONNECT='. Additionnaly, this patch provides an admnistrative server "bound" to the Ident server : on the administrative socket (default port 127.0.0.1:790), you can request number of users currently connected and list them. How to use this patch ? You just have to add a 'identServer=yes' directive to services that you want to propagate identification. For example, you can use this patch when connecting to a DansGuardian web proxy (installed on proxy.example.com) with the option authplugin = '/etc/dansguardian/ authplugins/ident.conf' enabled in the configuration file (or when connecting to a Squid web proxy compiled with --enable-ident-lookups option), and the following stunnel configuration file (located in /etc/ssl/stunnel/stunnel-ident.conf) : ... [WEB] accept=8080 connect=proxy.example.com:8080 identServer=yes ... Stunnel will create a listening socket on 0.0.0.0:113 and answer requests initiated by DansGuardian. -- Christophe Nanteuil

2 4

Stunnel seems broken with oracle http server
by Mailing List SVR 01 Feb '09

01 Feb '09

Hi all, stunnel seems broken with https served by oracle http server, look at the following one for example: https://www.orange.sk/ I'm not able to have http->to https working with that web site, it is a stunnel specific problem or an oracle one? thanks Nicola

2 2