January 2013 - 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

Problem with roundrobbin failover mode?
by Matt Wise 01 May '13

01 May '13

I've got dozens of clients connecting with Stunnel to a group of 5 servers. Each system has a config that looks like this: > cert = /etc/stunnel/zookeeper.pem > key = /etc/stunnel/zookeeper.key > CAfile = /etc/stunnel/zookeeper_ca.pem > verify = 2 > delay = yes > sslVersion = TLSv1 > client = yes > setuid = stunnel4 > setgid = stunnel4 > pid = /var/lib/stunnel4/zookeeper.stunnel4.pid > socket = l:TCP_NODELAY=1 > socket = r:TCP_NODELAY=1 > TIMEOUTconnect = 2 > session = 86400 > debug = 5 > [zookeeper] > accept = 127.0.0.1:2182 > failover = rr > connect = prod-zookeeper:2182 > connect = prod-zookeeper-1:2182 > connect = prod-zookeeper-2:2182 > connect = prod-zookeeper-3:2182 > connect = prod-zookeeper-4:2182 > connect = prod-zookeeper-5:2182 Essentially the first host is a load balancer, and the next 5 are the actual zookeeper hosts so that we can bypass the ELB if its giving us fits. Now what we're seeing is that almost every connection ends up on prod-zookeeper-5. Over and over and over again, our hosts pick the same system each time. We're running Stunnel 4.52: > Clients allowed=8000 > stunnel 4.52 on i486-pc-linux-gnu platform > Compiled/running with OpenSSL 0.9.8k 25 Mar 2009 > Threading:PTHREAD SSL:ENGINE Auth:LIBWRAP Sockets:POLL,IPv6 Any ideas what might be wrong here? Obviously we want the connections to be *roughly* random across the list of hosts... and if one of the hosts goes down, and the connection fails, we want the stunnel service to try again, and randomly pick a new host. It doesn't really seem to be doing that though. --Matt

3 8

Fw: High memory usage problem.
by mkanet＠yahoo.com 27 Mar '13

27 Mar '13

Jeremy, I know there's an android build of stunnel. Im not trying to be funny, but are you running stunnel on your mobile phone? :) The latest android mobile phones include quadcore CPU's with 2GB's of RAM It would be interesting to see how much of a load a mobile phone can handle with a USB to RJ45 Ethernet interface. Edit: I tried sending this earlier, but it doesn't look like it went through. My apologies in case this is a duplicate. ------------------------ Thanks for taking the time to read this. We're operating on a low spec system that can not be modified at this point. stunnel was introduced at the last minute, without consideration to resource requirements and now consumes enough ram to cause the kernel to issue OOM exceptions. So in short, we are trying to trade increased CPU usage for less memory usage and have tried setting “sessions” to 3600 to reduce memory pressure, but unfortunately it doesn't last. Our current solution is to cron a restart of stunnel on a regular basis, but would prefer to limit number of threads or number of cache entries or something else altogether similarly gentler. Thanks again for your consideration and assistance in this! If there's any specific information I can give, please let me know. Regards, Jeremy

3 7

transfer() loop executes not transferring any data and truncated data when using unix sockets
by Stephen Balukoff 08 Feb '13

08 Feb '13

Hello! Recently we started seeing some erroneous behavior in one of our load balancer configurations in which we're using stunnel for SSL tunnel termination with web clients. Specifically, the setup looks like the following: Web client ---(SSL)---> stunnel ---(unix socket)--> haproxy ---(tcp/http)---> web server After extensive troubleshooting we were able to determine that when the following parameters are present: * Client forces non-keepalive connection * Client generates a POST request, the response to which (generated by the back-end web server) is greater than about 8k * stunnel and haproxy communicate via unix socket ...then most responses end up being truncated by an extraneous TCP RST packet from stunnel, and the following log lines are generated: Jan 23 15:24:17 ds420a stunnel: LOG3[22586:139835614443264]: transfer() loop executes not transferring any data Jan 23 15:24:17 ds420a stunnel: LOG3[22586:139835614443264]: please report the problem to Michal.Trojnara(a)mirt.net Jan 23 15:24:17 ds420a stunnel: LOG3[22586:139835614443264]: stunnel 4.54 on x86_64-unknown-linux-gnu platform Jan 23 15:24:17 ds420a stunnel: LOG3[22586:139835614443264]: Compiled/running with OpenSSL 1.0.0-fips 29 Mar 2010 Jan 23 15:24:17 ds420a stunnel: LOG3[22586:139835614443264]: Threading:PTHREAD SSL:+ENGINE+OCSP+FIPS Auth:none Sockets:POLL+IPv6 Jan 23 15:24:17 ds420a stunnel: LOG3[22586:139835614443264]: protocol=TLSv1, SSL_pending=0 Jan 23 15:24:17 ds420a stunnel: LOG3[22586:139835614443264]: sock_open_rd=n, sock_open_wr=Y Jan 23 15:24:17 ds420a stunnel: LOG3[22586:139835614443264]: SSL_RECEIVED_SHUTDOWN=n, SSL_SENT_SHUTDOWN=Y Jan 23 15:24:17 ds420a stunnel: LOG3[22586:139835614443264]: sock_can_rd=Y, sock_can_wr=n Jan 23 15:24:17 ds420a stunnel: LOG3[22586:139835614443264]: ssl_can_rd=n, ssl_can_wr=n Jan 23 15:24:17 ds420a stunnel: LOG3[22586:139835614443264]: read_wants_read=Y, read_wants_write=n Jan 23 15:24:17 ds420a stunnel: LOG3[22586:139835614443264]: write_wants_read=n, write_wants_write=n Jan 23 15:24:17 ds420a stunnel: LOG3[22586:139835614443264]: shutdown_wants_read=n, shutdown_wants_write=n Jan 23 15:24:17 ds420a stunnel: LOG3[22586:139835614443264]: socket input buffer: 0 byte(s), ssl input buffer: 0 byte(s) The work arounds we have found are either: 1. Make stunnel and haproxy communicate over a TCP socket bound to the loopback interface (less ideal, as then we're limited to 65k connections) 2. Add the "reset=no" parameter to our stunnel.conf (which seems to fix the problem, but makes me wonder if we're not opening ourselves up to other problems-- like really getting stuck in an infinite loop that that watchdog is intended to avoid.) In any case based on what "reset=no" is supposed to do as well as where that first line of the error output above is being generated in the code, it's clear that the main client data transfer loop in client.c (starting line 519) is being called too often with no data to transfer, which triggers the infinite loop detection in the transfer() function (client.c, starting line 832). My best hypothesis at this point is that the transfer() code was written only with TCP sockets in mind, and that something about the unix socket in use here is triggering that loop too often. Maybe s_poll_wait on line 541 is being called with parameters which are right for a TCP socket but inappropriate for a unix socket? At this point though, we're at the limit of my socket programming ability, so I'm a little stuck. (Would like to have simply fixed this and submitted a patch... but cest la vie, eh.) We'd like to avoid using a TCP socket to communicate between stunnel and haproxy simply because it's a little less efficient, and because there's an artificial 65k limit on the number of back-end connections we can support per loopback IP if we do that. Alternatively, if someone could verify that "reset=no" is an acceptable / safe work around in this case, I'd appreciate that (though, of course, I'd prefer my logs not to get spammed on every connection. :P ) Is there any other data I can provide to help troubleshoot and fix this? Thanks, Stephen -- Stephen Balukoff Blue Box Group, LLC (800)613-4305 x807

3 3

fix resource leaks and potential null dereferences in 4.54
by Arthur Mesh 03 Feb '13

03 Feb '13

Hi, I am trying to figure out where bug reports should be submitted. https://www.stunnel.org/lists.html references this mailing list, so here is my attempt at a bug report with a potential fix. If this is not an appropriate list, please redirect me. A coverity run has uncovered quite a few memory and other resource leaks, plus some potential NULL dereferences. Inline is an attempt to fix them. Imho, these are mostly self-explanatory, but if someone needs more details, I would be happy to provide those as well. Thanks diff -ru stunnel-4.54/src/options.c stunnel-4.54.p/src/options.c --- stunnel-4.54/src/options.c 2012-10-09 01:50:54.000000000 -0700 +++ stunnel-4.54.p/src/options.c 2013-01-29 16:26:00.000000000 -0800 @@ -1988,7 +1988,7 @@ int parse_conf(char *name, CONF_TYPE type) { DISK_FILE *df; - char line_text[CONFLINELEN], *errstr; + char line_text[CONFLINELEN], *errstr = NULL; char config_line[CONFLINELEN], *config_opt, *config_arg; int line_number, i; SERVICE_OPTIONS *section, *new_section; @@ -2104,7 +2104,8 @@ errstr=parse_service_option(CMD_END, section, NULL, NULL); } if(errstr) { - s_log(LOG_ERR, "Service [%s]: %s", section->servname, errstr); + s_log(LOG_ERR, "Service [%s]: %s", section ? section->servname : "", + errstr); return 1; } @@ -2253,7 +2254,7 @@ } new_global_options.debug_level=8; /* illegal level */ for(fl=levels; fl->name; ++fl) { - if(!strcasecmp(fl->name, string)) { + if(string && !strcasecmp(fl->name, string)) { new_global_options.debug_level=fl->value; break; } @@ -2428,6 +2429,7 @@ if(get_last_socket_error()!=S_ENOPROTOOPT) { s_log(LOG_ERR, "Failed to get %s OS default", ptr->opt_str); sockerror("getsockopt"); + close(fd); return 1; /* FAILED */ } td=str_dup("write-only"); @@ -2442,6 +2444,7 @@ ptr->opt_str, ta, tl, tr, td); str_free(ta); str_free(tl); str_free(tr); str_free(td); } + close(fd); return 0; /* OK */ } Only in stunnel-4.54.p/src: options.c.orig diff -ru stunnel-4.54/src/protocol.c stunnel-4.54.p/src/protocol.c --- stunnel-4.54/src/protocol.c 2012-10-09 01:46:47.000000000 -0700 +++ stunnel-4.54.p/src/protocol.c 2013-01-29 16:26:00.000000000 -0800 @@ -244,30 +244,36 @@ /**************************************** smtp */ static void smtp_client(CLI *c) { - char *line; + char *line = NULL; do { /* copy multiline greeting */ + str_free(line); /* okay to str_free(NULL) */ line=fd_getline(c, c->remote_fd.fd); fd_putline(c, c->local_wfd.fd, line); } while(isprefix(line, "220-")); fd_putline(c, c->remote_fd.fd, "EHLO localhost"); do { /* skip multiline reply */ + str_free(line); line=fd_getline(c, c->remote_fd.fd); } while(isprefix(line, "250-")); if(!isprefix(line, "250 ")) { /* error */ + str_free(line); s_log(LOG_ERR, "Remote server is not RFC 1425 compliant"); longjmp(c->err, 1); } fd_putline(c, c->remote_fd.fd, "STARTTLS"); do { /* skip multiline reply */ + str_free(line); line=fd_getline(c, c->remote_fd.fd); } while(isprefix(line, "220-")); if(!isprefix(line, "220 ")) { /* error */ + str_free(line); s_log(LOG_ERR, "Remote server is not RFC 2487 compliant"); longjmp(c->err, 1); } + str_free(line); } static void smtp_server(CLI *c) { @@ -290,21 +296,27 @@ line=fd_getline(c, c->remote_fd.fd); if(!isprefix(line, "220")) { s_log(LOG_ERR, "Unknown server welcome"); + str_free(line); longjmp(c->err, 1); } fd_printf(c, c->local_wfd.fd, "%s + stunnel", line); + str_free(line); line=fd_getline(c, c->local_rfd.fd); if(!isprefix(line, "EHLO ")) { s_log(LOG_ERR, "Unknown client EHLO"); + str_free(line); longjmp(c->err, 1); } fd_printf(c, c->local_wfd.fd, "250-%s Welcome", line); + str_free(line); fd_putline(c, c->local_wfd.fd, "250 STARTTLS"); line=fd_getline(c, c->local_rfd.fd); if(!isprefix(line, "STARTTLS")) { s_log(LOG_ERR, "STARTTLS expected"); + str_free(line); longjmp(c->err, 1); } + str_free(line); fd_putline(c, c->local_wfd.fd, "220 Go ahead"); } @@ -316,15 +328,19 @@ line=fd_getline(c, c->remote_fd.fd); if(!isprefix(line, "+OK ")) { s_log(LOG_ERR, "Unknown server welcome"); + str_free(line); longjmp(c->err, 1); } fd_putline(c, c->local_wfd.fd, line); + str_free(line); fd_putline(c, c->remote_fd.fd, "STLS"); line=fd_getline(c, c->remote_fd.fd); if(!isprefix(line, "+OK ")) { s_log(LOG_ERR, "Server does not support TLS"); + str_free(line); longjmp(c->err, 1); } + str_free(line); } static void pop3_server(CLI *c) { @@ -332,17 +348,21 @@ line=fd_getline(c, c->remote_fd.fd); fd_printf(c, c->local_wfd.fd, "%s + stunnel", line); + str_free(line); line=fd_getline(c, c->local_rfd.fd); if(isprefix(line, "CAPA")) { /* client wants RFC 2449 extensions */ fd_putline(c, c->local_wfd.fd, "+OK Stunnel capability list follows"); fd_putline(c, c->local_wfd.fd, "STLS"); fd_putline(c, c->local_wfd.fd, "."); + str_free(line); line=fd_getline(c, c->local_rfd.fd); } if(!isprefix(line, "STLS")) { + str_free(line); s_log(LOG_ERR, "Client does not want TLS"); longjmp(c->err, 1); } + str_free(line); fd_putline(c, c->local_wfd.fd, "+OK Stunnel starts TLS negotiation"); } @@ -353,18 +373,22 @@ line=fd_getline(c, c->remote_fd.fd); if(!isprefix(line, "* OK")) { + str_free(line); s_log(LOG_ERR, "Unknown server welcome"); longjmp(c->err, 1); } fd_putline(c, c->local_wfd.fd, line); + str_free(line); fd_putline(c, c->remote_fd.fd, "stunnel STARTTLS"); line=fd_getline(c, c->remote_fd.fd); if(!isprefix(line, "stunnel OK")) { + str_free(line); fd_putline(c, c->local_wfd.fd, "* BYE stunnel: Server does not support TLS"); s_log(LOG_ERR, "Server does not support TLS"); longjmp(c->err, 2); /* don't reset */ } + str_free(line); } static void imap_server(CLI *c) { @@ -387,6 +411,7 @@ /* process server welcome and send it to client */ line=fd_getline(c, c->remote_fd.fd); if(!isprefix(line, "* OK")) { + str_free(line); s_log(LOG_ERR, "Unknown server welcome"); longjmp(c->err, 1); } @@ -396,22 +421,29 @@ if(capa) *capa='K'; /* disable CAPABILITY within greeting */ fd_printf(c, c->local_wfd.fd, "%s (stunnel)", line); + str_free(line); while(1) { /* process client commands */ line=fd_getline(c, c->local_rfd.fd); /* split line into id and tail */ id=str_dup(line); tail=strchr(id, ' '); - if(!tail) + if(!tail) { + str_free(line); + str_free(id); break; + } *tail++='\0'; if(isprefix(tail, "STARTTLS")) { fd_printf(c, c->local_wfd.fd, "%s OK Begin TLS negotiation now", id); + str_free(line); + str_free(id); return; /* success */ } else if(isprefix(tail, "CAPABILITY")) { fd_putline(c, c->remote_fd.fd, line); /* send it to server */ + str_free(line); line=fd_getline(c, c->remote_fd.fd); /* get the capabilites */ if(*line=='*') { /* @@ -421,6 +453,7 @@ * LOGIN would fail as "unexpected command", anyway */ fd_printf(c, c->local_wfd.fd, "%s STARTTLS", line); + str_free(line); line=fd_getline(c, c->remote_fd.fd); /* next line */ } fd_putline(c, c->local_wfd.fd, line); /* forward to the client */ @@ -429,24 +462,35 @@ fd_putline(c, c->local_wfd.fd, "* BYE unexpected server response"); s_log(LOG_ERR, "Unexpected server response: %s", line); + str_free(line); + str_free(id); break; } + str_free(line); + str_free(id); } else if(isprefix(tail, "LOGOUT")) { fd_putline(c, c->local_wfd.fd, "* BYE server terminating"); fd_printf(c, c->local_wfd.fd, "%s OK LOGOUT completed", id); + str_free(id); + str_free(line); break; } else { fd_putline(c, c->local_wfd.fd, "* BYE stunnel: unexpected command"); fd_printf(c, c->local_wfd.fd, "%s BAD %s unexpected", id, tail); s_log(LOG_ERR, "Unexpected client command %s", tail); + str_free(line); + str_free(id); break; } } /* clean server shutdown */ fd_putline(c, c->remote_fd.fd, "stunnel LOGOUT"); line=fd_getline(c, c->remote_fd.fd); - if(*line=='*') + if(*line=='*') { + str_free(line); line=fd_getline(c, c->remote_fd.fd); + } + str_free(line); longjmp(c->err, 2); /* don't reset */ } @@ -458,15 +502,19 @@ line=fd_getline(c, c->remote_fd.fd); if(!isprefix(line, "200 ") && !isprefix(line, "201 ")) { s_log(LOG_ERR, "Unknown server welcome"); + str_free(line); longjmp(c->err, 1); } fd_putline(c, c->local_wfd.fd, line); fd_putline(c, c->remote_fd.fd, "STARTTLS"); + str_free(line); line=fd_getline(c, c->remote_fd.fd); if(!isprefix(line, "382 ")) { s_log(LOG_ERR, "Server does not support TLS"); + str_free(line); longjmp(c->err, 1); } + str_free(line); } /**************************************** connect */ @@ -548,13 +596,17 @@ /* not "HTTP/1.0 200 Connection established" */ s_log(LOG_ERR, "CONNECT request rejected"); do { /* read all headers */ + str_free(line); line=fd_getline(c, c->remote_fd.fd); } while(*line); + str_free(line); longjmp(c->err, 1); } + str_free(line); s_log(LOG_INFO, "CONNECT request accepted"); do { line=fd_getline(c, c->remote_fd.fd); /* read all headers */ + str_free(line); } while(*line); } @@ -588,10 +640,13 @@ if(line[9]!='4' || line[10]!='0' || line[11]!='7') { /* code 407 */ s_log(LOG_ERR, "NTLM authorization request rejected"); do { /* read all headers */ + str_free(line); line=fd_getline(c, c->remote_fd.fd); } while(*line); + str_free(line); longjmp(c->err, 1); } + str_free(line); ntlm2_txt=NULL; do { /* read all headers */ line=fd_getline(c, c->remote_fd.fd); @@ -599,6 +654,7 @@ ntlm2_txt=str_dup(line+25); else if(isprefix(line, "Content-Length: ")) content_length=atol(line+16); + str_free(line); } while(*line); if(!ntlm2_txt) { /* no Proxy-Authenticate: NTLM header */ s_log(LOG_ERR, "Proxy-Authenticate: NTLM header not found"); Only in stunnel-4.54.p/src: protocol.c.orig diff -ru stunnel-4.54/src/stunnel.c stunnel-4.54.p/src/stunnel.c --- stunnel-4.54/src/stunnel.c 2012-08-18 14:11:53.000000000 -0700 +++ stunnel-4.54.p/src/stunnel.c 2013-01-29 16:26:00.000000000 -0800 @@ -119,12 +119,16 @@ fatal("Could not open /dev/null"); #endif /* standard Unix */ main_initialize(); - if(main_configure(argc>1 ? argv[1] : NULL, argc>2 ? argv[2] : NULL)) + if(main_configure(argc>1 ? argv[1] : NULL, argc>2 ? argv[2] : NULL)) { + close(fd); return 1; + } if(service_options.next) { /* there are service sections -> daemon mode */ #if !defined(__vms) && !defined(USE_OS2) - if(daemonize(fd)) + if(daemonize(fd)) { + close(fd); return 1; + } close(fd); /* create_pid() must be called after drop_privileges() * or it won't be possible to remove the file on exit */ Only in stunnel-4.54.p/src: stunnel.c.orig

3 4

X509 certificate info extract and use
by Pierre-Yves Bonnetain 03 Feb '13

03 Feb '13

Hello, We're looking for a way to add some kind of cross-control between an application and the TLS tunnelling tool that protects the data. I'll give an example, that may be easier to understand. My BigDatabase has it's login/password authentication process. Since my customers want to access the database through bad Internet, we set up a SSL/TLS frontend. Each customer has his own X509 certificate, with all proper bells and jingles in it. The frontend checks the certificate (CA sig, validity, revocation, etc.) and then, as it should, passes the unencrypted flow to the application. There is no way (or, rather, we have not found any way) to cross-check that the certificate AND the requested, application-level login, are linked together. This means that my evil neighbour, which bribed my gullible cat to get my login and password, could connect to my account (app-level auth) using his X509 cert (TLS tunnel auth). We would like to perform this cross-check between X509 certificate AND application-level auth. >From our point of view, this means that we need to "extract and send" some parts of the certificate (DN, validity dates, etc.) to some secondary tool/proxy. This one will check if the data is coherent wrt application credentials. M. Henrik Riomar sent a patch (http://www.stunnel.org/pipermail/stunnel-users/2012-October/003909.html) on the list last october that is one step closer to what we are looking for. We could build from it. Maybe some of you have already solved this kind of problem, or know of a tool that answer to this kind of needs ? Tia, -- Pierre-Yves Bonnetain-Nesterenko B&A Consultants - Sécurité informatique - www.ba-consultants.fr Tel. : +33 (0) 563 277 241 - Fax : +33 (0) 567 737 829

2 5

transparent proxy ssl for a socket server
by Alex Needham 29 Jan '13

29 Jan '13

Hi I have to figure out how to get some ssl encapsulation for an application we have that only servs on obscure ports, the app needs to retain the source ip adress of the client requests. So i looked at stunnel, its working great in transparent mode where the stunnel server is the default gateway of the socket server, but I would like to get the stunnel server onto the same machine as the socket server and keep the client src ip. Testing with a apache as a backend as its easy to test. running centos 6.3 (2.6.32-279.19.1.el6.x86_64), updated an hour ago, built stunnel 4.54 from src.rpm. The players stunnel-boxen external=192.168.0.1, internal=192.168.1.1 web/socket-boxen internal=192.168.1.11, dg=192.168.1.1 The configs Config A - works ok debug = 7 foreground = yes #not chrooted runnnig as root no setuid,setguid [socket-1234] cert=blarg.crt key=blarg.key accept = 192.168.0.1:1234 connect = 192.168.1.11:80 transparent = source Config B - Not so good connect = 192.168.1.1:80 <- inside interface of stunnel box iptables -t mangle -N DIVERT iptables -t mangle -A PREROUTING -p tcp -m socket -j DIVERT iptables -t mangle -A DIVERT -j MARK --set-mark 1 iptables -t mangle -A DIVERT -j ACCEPT ip rule add fwmark 1 lookup 100 ip route add local 0.0.0.0/0 dev lo table 100 /etc/sysctl.conf no route filtering and forwarding is on am i trying something impossible? or am i missing something? Any help greatly appreciated, if I get this going I'll happily do a nice neater write up for others. Cheers Alex

2 1

child process reaping
by Michael Weiser 29 Jan '13

29 Jan '13

Hello, recent versions (4.47+ I think) of stunnel introduce the following code in stunnel.c: --- stunnel-4.46/src/stunnel.c 2011-11-03 10:06:59.000000000 +0100 +++ stunnel-4.54/src/stunnel.c 2012-08-18 23:11:53.000000000 +0200 [...] } else { /* inetd mode */ [...] + signal(SIGCHLD, SIG_IGN); /* ignore dead children */ + signal(SIGPIPE, SIG_IGN); /* ignore broken pipe */ + client_main(alloc_client_session(&service_options, 0, 1)); } In Linux, child processes seem to inherit their parent's SIGCHLD handler setting. This means that all of stunnel's child processes will be unable to wait for their children. This causes the following uucp-over-stunnel setup I have: CAfile = /etc/ssl/certs/cacert.pem cert = /etc/ssl/certs/suucpcert.pem key = /etc/ssl/private/suucpkey.unenc verify = 2 service = suucp exec = /usr/sbin/uucico execargs = uucico -l to fail horribly with messages such as this: uucico weiser - (2013-01-29 01:25:15.33 3676) Call complete (6 seconds 21620 bytes 35103 bps) uuxqt weiser root (2013-01-29 01:25:17.36 3677) Executing X.weiserSEQ1 (rbsmtp) uuxqt weiser root (2013-01-29 01:25:17.96 3677) ERROR: waitpid: No child processes uuxqt weiser root (2013-01-29 01:25:17.96 3677) Execution failed (X.weiserSEQ1) Restoring SIGCHLD to SIG_DFL just before execvp()'ing the child as in the attached patch seems to fix it. I also attach a small test case for reproducing. It can be run like this: nc -l -p 12345 -e "stunnel sigchldtest.conf" 127.0.0.1 & openssl s_client -quiet -verify 0 -connect 127.0.0.1:12345 and should produce the following output: child: 2654 child 2654 died When automatic child reaping it active it will fail like this: child: 2538 waitpid: No child processes BTW: On Mac OS X, the SIGCHLD handler setting does not seem to be inherited by children. -- Thanks, Micha

1 0

MATCH CERT AGAINST LDAP
by Alejandro Fernandez 26 Jan '13

26 Jan '13

Hi there! I would like to know if it's possible with stunnel, as is, to match a client certificate against a certstore in a directory service, instead of a file, so to be able to revoke from a service such as Fedora 389 some access. Please, understand that the idea is not to access the LDAP itself, but to access some service within a network and grant such access based on a directory service query. Thanks everyone, Alejandro

1 0