stunnel-users

stunnel-users@stunnel.org

5 participants
3293 discussions

Re: [stunnel-users] safestring and safename insecure
by Hans Werner Strube 24 Aug '06

24 Aug '06

Michal Trojnara wrote: > Assuming on some systems isprint(x) != isprint(x&0xff): any idea how to > exploit this "insecure" code? > > BTW: At least on Linux and Mac OS X isprint() returns 0 in both cases. The same holds for Solaris. I did not actually encounter an error but just got the idea that something may be insecure here by looking at the lines. After all, isprint etc. are often table-based macros without range-checking the argument. And "man isprint" clearly says that the character is unsigned: (Solaris:) The macro isascii() is defined on all integer values; the rest are defined only where the argument is an int, the value of which is representable as an unsigned char, or EOF, (Linux:) These functions check whether c, which must have the value of an unsigned char or EOF, falls into a certain character class according to the current locale.

1 0

safestring and safename insecure
by Hans Werner Strube 24 Aug '06

24 Aug '06

The macros safestring and safename in common.h are insecure if called for a character with high bit set, because (int)*p will sign-extend the byte on machines where char is signed. Possible patch (here for safestring; for safename correspondingly with isprint -> isalnum): do {char *p; for(p=(s); *p; p++) if(!isprint((int)*(unsigned char *)p)) *p='.';} while(0)

2 1

Re: [stunnel-users] accept is not allowed in inetd mode
by Tomasz Feliksiak 24 Aug '06

24 Aug '06

> I'm afraid I won't be able to tell you what's wrong with your > /etc/stunnel/smtps.conf without your /etc/stunnel/smtps.conf file. > 8-) > I guess you didn't define any service section. > > BTW. Please make sure to read the fine manual. There's also a Polish > version. > http://stunnel.mirt.net/static/stunnel.pl.html > > Greetings from Poland, > Mike You were right. I only define ports but dont uncomment protocol names in [] (like [pop3s]). [pop3s] accept = 995 connect = 110 ;[imaps] ;accept = 993 ;connect = 143 [ssmtp] accept = 465 connect = 25 Now it looks like this and it's working (earlier i have two configs, one per service). Poor thing about this is that it don't log anything before you dont uncomment this [] :P - hope no one other make this mistake. When I uncomment everything else was simple cause I have log :) and know what's going on. There was a problem with binding to ports cause I try to run it by inetd but I find your post at google to not run it by inetd. I change stunnel-inetd-4.15-1 to stunnel-standalone-4.15-1 (PLD Rulez :P) and problems gone. Is possible to run stunnel by inetd??? Thanks for help Michal. Stunnel is great :) Ps. I read the manual, english version. Sad thing is that I dont find out where I make mistake and when I read Polish wersion I do. Good thing is that it will be help for others who make this simple mistake. -- Pozdrawiam Tomasz Feliksiak vonom(a)intertel.net.pl

2 2

Stunnel Crash: Gmail SMTP over TLS
by Shatadal Ghosh 23 Aug '06

23 Aug '06

Hi, I am using stunnel 4.15 on Windows XP SP1 with Mozilla Thunderbird as the e-mail client. I do not have openSSL installed locally. I do have the libssl32.dll and libeay32.dll in the same directory as stunnel.exe (C:\Program Files\stunnel). I am running stunnel as a service. Stunnel crashes when I use it to send e-mail (SMTP via TLS) via gmail. According to the e-mail client configuration page on the gmail website http://mail.google.com/support/bin/answer.py?answer=13287&topic=1555 I tried to use SMTP over TLS to connect to smtp.gmail.com:587 My gmail-smtps block in stunnel.conf was ; SMTP service, listens on localhost:250 [gmail-smtps] protocol=smtp accept=localhost:250 connect=smtp.gmail.com:587 On trying to send an e-mail message via the above configuration stunnel crashed. The log file is as follows 2006.06.14 03:17:15 LOG5[3956:3512]: stunnel 4.15 on x86-pc-mingw32-gnu with OpenSSL 0.9.7i 14 Oct 2005 2006.06.14 03:17:15 LOG5[3956:3512]: Threading:WIN32 SSL:ENGINE Sockets:SELECT,IPv6 2006.06.14 03:17:15 LOG5[3956:3600]: No limit detected for the number of clients 2006.06.14 03:17:15 LOG7[3956:3600]: FD 172 in non-blocking mode 2006.06.14 03:17:15 LOG7[3956:3600]: SO_REUSEADDR option set on accept socket 2006.06.14 03:17:15 LOG7[3956:3600]: gmail-pop3s bound to 127.0.0.1:1100 2006.06.14 03:17:15 LOG7[3956:3600]: FD 180 in non-blocking mode 2006.06.14 03:17:15 LOG7[3956:3600]: SO_REUSEADDR option set on accept socket 2006.06.14 03:17:15 LOG7[3956:3600]: gmail-smtps bound to 127.0.0.1:250 ....# info about other mail connections 2006.06.14 03:17:26 LOG7[3956:3600]: gmail-smtps accepted FD=236 from 127.0.0.1:3665 2006.06.14 03:17:26 LOG7[3956:3600]: Creating a new thread 2006.06.14 03:17:26 LOG7[3956:3600]: New thread created 2006.06.14 03:17:26 LOG7[3956:2812]: gmail-smtps started 2006.06.14 03:17:26 LOG7[3956:2812]: FD 236 in non-blocking mode 2006.06.14 03:17:26 LOG7[3956:2812]: TCP_NODELAY option set on local socket 2006.06.14 03:17:26 LOG5[3956:2812]: gmail-smtps connected from 127.0.0.1:3665 2006.06.14 03:17:26 LOG7[3956:2812]: FD 268 in non-blocking mode 2006.06.14 03:17:26 LOG7[3956:2812]: gmail-smtps connecting 64.233.167.111:587 2006.06.14 03:17:26 LOG7[3956:2812]: connect_wait: waiting 10 seconds 2006.06.14 03:17:26 LOG7[3956:2812]: connect_wait: connected 2006.06.14 03:17:26 LOG7[3956:2812]: Remote FD=268 initialized 2006.06.14 03:17:26 LOG7[3956:2812]: TCP_NODELAY option set on remote socket 2006.06.14 03:17:26 LOG5[3956:2812]: Negotiations for smtp (client side) started 2006.06.14 03:17:26 LOG7[3956:2812]: <- 220 mx.gmail.com ESMTP w66sm450524pyw 2006.06.14 03:17:26 LOG7[3956:2812]: -> 220 mx.gmail.com ESMTP w66sm450524pyw <logfile ends> What mistake am I making? Fortunately it seems that gmail supports SMTP over SSL too (smtp.gmail.com:465) and I am using that. However I am also facing this problem with another account which unfortunately allows SMTP only over TLS. Thanks, Shatadal. --- avast! Antivirus: Outbound message clean. Virus Database (VPS): 0624-1, 06/13/2006 Tested on: 6/14/2006 6:22:04 AM avast! - copyright (c) 2000-2006 ALWIL Software. http://www.avast.com _________________________________________________________________ Is your PC infected? Get a FREE online computer virus scan from McAfee® Security. http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963

2 1

Re: [stunnel-users] RFC 2487 test in smtp_server not reliable
by Hans Werner Strube 23 Aug '06

23 Aug '06

Michal Trojnara wrote: > On 2006-08-22, at 10:55, Hans Werner Strube wrote: > > Instead of waiting, a better method would > > be to have a finer timeout resolution than 1 sec in > > s_poll_wait(...,...); > > setting the timeout to 1 (sec) would be too embarrassing for TLS > > connections. But this would require major changes in the sources. > > I'm going to do it the hard way and add another parameter to > s_poll_wait() function. > > IMHO the timeout should be between 100ms and 500ms. What do you think? I have not tested the minimum required. However, it should be as short as possible, since for a client using TLS, the full delay will always occur on starting a connection. It should be documented somewhere how this new constant could be configured in compilation.

1 0

RFC 2487 test in smtp_server not reliable
by Hans Werner Strube 23 Aug '06

23 Aug '06

In protocol.c, function smtp_server(), a test for plain SSL or STARTTLS usage (RFC 2487) is based on the availability of data from the client (c->local_rfd.fd). This works well in fast LANs but often fails for WAN connections through slow V90 modems. Especially with new Mozilla-based clients (also KMail and Evolution reported by other users) under Windows XP SP2 the test for data fails almost always, incorrectly resulting in an RFC 2487 handshake with error "Unknown client EHLO". This depends to some extent on the client: Outlook Express mostly works, Mozilla 1.7.x often worked after initial failure, SeaMonkey 1.x always fails. This seems to be a timing problem. I tried inserting a "usleep(50000);" before the switch(s_poll_wait(...)), which made SSL work with SeaMonkey (but often not for the first mail-sending attempt). Unfortunately, in Solaris 7 (where I tested stunnel), usleep is not yet thread-safe, maybe nanosleep(...,...) is preferable. Instead of waiting, a better method would be to have a finer timeout resolution than 1 sec in s_poll_wait(...,...); setting the timeout to 1 (sec) would be too embarrassing for TLS connections. But this would require major changes in the sources.

2 1

accept is not allowed in inetd mode
by vonom 23 Aug '06

23 Aug '06

Hello When i try to run stunnel by scripts or by hand stunnel /etc/stunnel/stunnel.conf (or other config) i see something like that: -bash-3.1# stunnel /etc/stunnel/pop3s.conf 2006.08.23 01:45:17 LOG7[24189:3083933376]: RAND_status claims sufficient entropy for the PRNG 2006.08.23 01:45:17 LOG6[24189:3083933376]: PRNG seeded successfully 2006.08.23 01:45:17 LOG7[24189:3083933376]: Certificate: /etc/stunnel/host-cert.pem 2006.08.23 01:45:17 LOG7[24189:3083933376]: Key file: /etc/stunnel/host-key.pem 2006.08.23 01:45:17 LOG7[24189:3083933376]: SSL context initialized for service stunnel file /etc/stunnel/pop3s.conf line 64: accept is not allowed in inetd mode No stunnel sesion, open ports or anything. I was very happy when I find out that I have stunnel-inetd-4.15-1 in my disto and it runs and ports are open. Everything great but when i try to send or receive email (postfix) it dont work. I spend a lot of time and a while ago i write telnet localhost 465 (or 995), ehlo hostname and see: -bash-3.1# telnet localhost 465 Trying 127.0.0.1.465... Connected to localhost. Escape character is '^]'. 2006.08.23 01:56:20 LOG7[24343:3083708096]: RAND_status claims sufficient entropy for the PRNG 2006.08.23 01:56:20 LOG6[24343:3083708096]: PRNG seeded successfully 2006.08.23 01:56:20 LOG7[24343:3083708096]: Certificate: /etc/stunnel/host-cert.pem 2006.08.23 01:56:20 LOG7[24343:3083708096]: Key file: /etc/stunnel/host-key.pem 2006.08.23 01:56:20 LOG7[24343:3083708096]: SSL context initialized for service stunnel file /etc/stunnel/smtps.conf line 64: accept is not allowed in inetd mode Connection closed by foreign host. When I write telnet localhost 25 -bash-3.1# telnet localhost 25 Trying 127.0.0.1.25... Connected to localhost. Escape character is '^]'. 250-PIPELINING 250-SIZE 10240000 250-VRFY 250-ETRN 250-STARTTLS 250 8BITMIME So It's OK I think. file /etc/stunnel/smtps.conf line 64: accept is not allowed in inetd mode Connection closed by foreign host. -line 64 point just last line of config file. I have no idea what it could be. Anyone know how to fix that?

2 1

Protocol using Connect
by Hutchison, Alan 21 Aug '06

21 Aug '06

I am trying to use the protocol entries in the config file as shown below (xyz substituted to protect employer & vendor). Below is the log. Stunnel abends as it is trying to authenticate to our corporate proxy. The network guys are seeing the attempt to authenticate but it does not appear to complete. Any thoughts? key=maxstpb.crt debug=7 output=stunnel.log client=yes [MarketAxess] accept=127.0.0.1:12345 delay=yes TIMEOUTbusy=120 TIMEOUTconnect=120 connect=xyz.xyz.com:80 protocol=connect protocolHost=xyz.xyz.com:443 protocolCredentials=xyz:xyz 2006.08.21 15:13:24 LOG5[2520:1312]: stunnel 4.15 on x86-pc-mingw32-gnu with OpenSSL 0.9.7i 14 Oct 2005 2006.08.21 15:13:24 LOG5[2520:1312]: Threading:WIN32 SSL:ENGINE Sockets:SELECT,IPv4 2006.08.21 15:13:24 LOG5[2520:3184]: No limit detected for the number of clients 2006.08.21 15:13:24 LOG7[2520:3184]: FD 192 in non-blocking mode 2006.08.21 15:13:24 LOG7[2520:3184]: SO_REUSEADDR option set on accept socket 2006.08.21 15:13:24 LOG7[2520:3184]: MarketAxess bound to 127.0.0.1:12345 2006.08.21 15:14:00 LOG7[2520:3184]: MarketAxess accepted FD=200 from 127.0.0.1:4200 2006.08.21 15:14:00 LOG7[2520:3184]: Creating a new thread 2006.08.21 15:14:00 LOG7[2520:3184]: New thread created 2006.08.21 15:14:00 LOG7[2520:2560]: MarketAxess started 2006.08.21 15:14:00 LOG7[2520:2560]: FD 200 in non-blocking mode 2006.08.21 15:14:00 LOG5[2520:2560]: MarketAxess connected from 127.0.0.1:4200 2006.08.21 15:14:00 LOG7[2520:2560]: FD 416 in non-blocking mode 2006.08.21 15:14:00 LOG7[2520:2560]: MarketAxess connecting xyz.xyz.xyz.xyz:80 2006.08.21 15:14:00 LOG7[2520:2560]: connect_wait: waiting 120 seconds 2006.08.21 15:14:00 LOG7[2520:2560]: connect_wait: connected 2006.08.21 15:14:00 LOG7[2520:2560]: Remote FD=416 initialized 2006.08.21 15:14:00 LOG5[2520:2560]: Negotiations for connect (client side) started 2006.08.21 15:14:00 LOG7[2520:2560]: -> CONNECT xyz.xyz.com:443 HTTP/1.1 Alan R. Hutchison 515-362-1272 -----Message Disclaimer----- This e-mail message is intended only for the use of the individual or entity to which it is addressed, and may contain information that is privileged, confidential and exempt from disclosure under applicable law. If you are not the intended recipient, any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by reply email to Connect(a)principal.com and delete or destroy all copies of the original message and attachments thereto. Email sent to or from the Principal Financial Group or any of its member companies may be retained as required by law or regulation. Nothing in this message is intended to constitute an Electronic signature for purposes of the Uniform Electronic Transactions Act (UETA) or the Electronic Signatures in Global and National Commerce Act ("E-Sign") unless a specific statement to the contrary is included in this message. While this communication may be used to promote or market a transaction or an idea that is discussed in the publication, it is intended to provide general information about the subject matter covered and is provided with the understanding that The Principal is not rendering legal, accounting, or tax advice. It is not a marketed opinion and may not be used to avoid penalties under the Internal Revenue Code. You should consult with appropriate counsel or other advisors on all matters pertaining to legal, tax, or accounting obligations and requirements.

1 0

limit connections per certificate
by Eric H. Jung 14 Aug '06

14 Aug '06

Hi, I'd like to limit the number of connections to stunnel (in server mode) by client certificate. In other words, I want all clients to only have 1 open socket connection to the server at a time. Is this possible with stunnel out-of-the-box, or must I write a patch to handle it? Thank you, grimholtz

1 0

stunnel through xinetd: process not terminating after use
by Alex Forrow 07 Aug '06

07 Aug '06

Hi, Im using stunnel through xinetd to forward some local unencrypted ldap connections to our ssl ldap server. Seems to work ok but after each use the stunnel process does not terminate, so I end up with losts of processes not doing anything. After a few days, these processes reach a limit and connections fail. As you can see, the connection has finished, but the process still exists: [root@lynx stunnel]# ps -e | grep stunnel 2396 ? 00:00:00 stunnel 2517 ? 00:00:00 stunnel 2575 ? 00:00:00 stunnel 2576 ? 00:00:00 stunnel [root@lynx stunnel]# netstat -p | grep stunnel tcp 0 0 lynx.seekit.co.uk:ldaplo lynx.seekit.co.uk:60390 CLOSE_WAIT 2396/stunnel unix 2 [ ] DGRAM 3204569 2576/stunnel unix 2 [ ] DGRAM 3204562 2575/stunnel unix 2 [ ] DGRAM 3203127 2517/stunnel unix 2 [ ] DGRAM 3202108 2396/stunnel Heres the xinetd configuration for stunnel (/etc/xinetd.d/ldaplo): # default: on # description: Stunnel to connect to LDAP for an insecure local session service ldaplo { disable = no #flags = REUSE port = 390 socket_type = stream wait = no user = nobody server = /usr/sbin/stunnel server_args = /etc/stunnel/ldap.conf # log_on_failure += USERID } Heres the stunnel configuration file (/etc/stunnel/ldap.conf): client = yes connect = 636 Cheers, Alex Forrow

1 0

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

stunnel-users