April 2009 - stunnel-users

OpenSSL Vulnerabilities
by Cal Webster 07 Apr '09

07 Apr '09

Will there be a security update of stunnel to address vulnerabilities outlined in CVE-2009-0590, CVE-2009-0591, and CVE-2009-0789? Alternatively, will stunnel use updated OpenSSL libraries on the host? It appears that this is true on Fedora RPM packages. For Example: ldd stunnel: ------------ libssl.so.7 => /lib64/libssl.so.7 (0x0000000006a3c000) libcrypto.so.7 => /lib64/libcrypto.so.7 (0x0000000007954000) ------------ rpm -q --requires stunnel ----------------------------------------- ... libcrypto.so.7 ... libssl.so.7 ... ----------------------------------------- rpm -ql openssl | egrep 'libcrypto.so.7|libssl.so.7' ----------------------------------------- /lib/libcrypto.so.7 /lib/libssl.so.7 ----------------------------------------- However, I don't know how to determine whether the same dependency works with Win32 dll's. For example, could we install "Win32 OpenSSL v0.9.8k Light" from the below link to resolve the vulnerabilities? http://www.slproweb.com/download/Win32OpenSSL_Light-0_9_8k.exe The description says that it "Installs the most commonly used essentials of Win32 OpenSSL v0.9.8k" but it doesn't say exactly what. Thanks for any insights or suggestions. Cal Webster

2 2

Re: [stunnel-users] Problem with name resolving when using delay option
by Michal Trojnara 06 Apr '09

06 Apr '09

Maksymilian Kowalik wrote: > So the workaround was as simple as creating etc directory inside chroot > and putting resolv.conf there. But still don't know whose bug it is > glibc's or stunnel's? It's not really a bug. It's rather an inherent property of chrooted environments. They often require some files and/or devices to work properly. Pozdrowienia z Polski, Mike

1 0

Re: [stunnel-users] Problem with name resolving when using delay option
by Aron Griffis 06 Apr '09

06 Apr '09

Maksymilian Kowalik wrote: [Mon Apr 06 2009, 08:56:02AM EDT] > So the workaround was as simple as creating etc directory > inside chroot and putting resolv.conf there. But still don't > know whose bug it is glibc's or stunnel's? Neither, it's your bug. :-) As you discovered, you need resolv.conf in the chroot. Aron

1 0

Updating OpenSSL used by stunnel
by Peter Droop 06 Apr '09

06 Apr '09

Hi, I am running stunnel 4.25 with openssl 0.9.8h on Windows 2003 Server. There are some security updates out for openssl, that are not available on stunnel.org. Can I update openssl by just replacing libeay32.dll and libssl32.dll in the stunnel installation directory? I downloaded the dlls from http://www.slproweb.com/products/Win32OpenSSL.html. Thanks, Peter

1 0

GPL patches
by Michal Trojnara 01 Apr '09

01 Apr '09

Dear Users, I've just uploaded some patches sent to stunnel-users list over the years to ftp://stunnel.mirt.net/stunnel/contrib/. Please remember my policy is *not* to include any GPL code into the official stunnel distribution. If you're brave you're free to apply the patches yourself, or even create a fork of stunnel with some additional functionality. Just be aware there were already some security vulnerabilities (including remote code execution) discovered in the 3rd party stunnel patches. For this reason I also don't recommend stunnel package/port maintainers to include any 3rd party code with stunnel. Best regards, Mike

1 0

Can't get NTLM authentication to work with proxy connect.
by Rudy Ghani 01 Apr '09

01 Apr '09

Hi there, My stunnel client is on an Active Directory-authenticated XP workstation, which needs to connect via a web proxy that authenticates using NTLM. I populated my login details in protocolUsername and protocolPassword, but the connection just dies when it reaches the proxy server. Looking at the log, I get the following:- 2009.04.01 08:20:39 LOG6[2140:2892]: SSL connected: new session negotiated 2009.04.01 08:20:39 LOG6[2140:2892]: Negotiated ciphers: AES256-SHA SSLv3 Kx=RSA Au=RSA Enc=AES(256) Mac=SHA1 2009.04.01 15:34:09 LOG7[2140:2708]: ssh3 accepted FD=356 from 127.0.0.1:1026 2009.04.01 15:34:09 LOG7[2140:2708]: Creating a new thread 2009.04.01 15:34:09 LOG7[2140:2708]: New thread created 2009.04.01 15:34:09 LOG7[2140:3896]: ssh3 started 2009.04.01 15:34:09 LOG7[2140:3896]: FD 356 in non-blocking mode 2009.04.01 15:34:09 LOG7[2140:3896]: TCP_NODELAY option set on local socket 2009.04.01 15:34:09 LOG5[2140:3896]: ssh3 accepted connection from 127.0.0.1:1026 2009.04.01 15:34:09 LOG7[2140:3896]: FD 472 in non-blocking mode 2009.04.01 15:34:09 LOG7[2140:3896]: ssh3 connecting 129.32.20.14:8080 2009.04.01 15:34:09 LOG7[2140:3896]: connect_wait: waiting 10 seconds 2009.04.01 15:34:09 LOG7[2140:3896]: connect_wait: connected 2009.04.01 15:34:09 LOG5[2140:3896]: ssh3 connected remote server from 130.32.82.203:1027 2009.04.01 15:34:09 LOG7[2140:3896]: Remote FD=472 initialized 2009.04.01 15:34:09 LOG7[2140:3896]: TCP_NODELAY option set on remote socket 2009.04.01 15:34:09 LOG5[2140:3896]: Negotiations for connect (client side) started 2009.04.01 15:34:09 LOG7[2140:3896]: -> CONNECT xxxx.ath.cx:443 HTTP/1.1 2009.04.01 15:34:09 LOG7[2140:3896]: -> Host: xxxx.ath.cx:443 2009.04.01 15:34:09 LOG7[2140:3896]: -> Proxy-Connection: keep-alive 2009.04.01 15:34:09 LOG7[2140:3896]: -> Proxy-Authorization: NTLM TlRMTVNTUAABAAAAAgIAAA== 2009.04.01 15:34:09 LOG7[2140:3896]: -> 2009.04.01 15:34:09 LOG3[2140:3896]: Unexpected socket close (fdgetline) 2009.04.01 15:34:09 LOG5[2140:3896]: Connection reset: 0 bytes sent to SSL, 0 bytes sent to socket 2009.04.01 15:34:09 LOG7[2140:3896]: ssh3 finished (1 left) If I decode the NTLM auth string, I only get the NTLMSSP header, which seems to be incomplete. If I recall correctly the domain and workstation info should be passed on as well. So question is, how do I get this to work? Is there any specific format that I need to use when using the protocol* settings for NTLM? Thanks and regards.

1 0