stunnel-users November 2005

stunnel-users@stunnel.org

22 participants
26 discussions

IPTables/Stunnel Help needed
by Alaric Dailey 08 Nov '05

08 Nov '05

Ok, I have a fairly complex firewall setup on my Linux box with 7 host IPs, 2 Internet connections, and a DMZ. I need to direct 1 IP to stunnel on the firewall to be forwarded to the mail server in the DMZ on ports 8383, 993, 995 etc.. but leave ports 25, and 3389 forwarded via iptables, can anyone lend a hand?

1 0

Re: [stunnel-users] Solaris: new_context, makecontext
by Hans Werner Strube 08 Nov '05

08 Nov '05

Michal Trojnara wrote: > I had no Solaris 10 to test it... So what's the correct way to detect > Solaris 10? This must probably be done by a modified configure and a new #if or #ifdef. uname -r gives 5.10 for Solaris 10. > Solaris 9 behaves correctly if __MAKECONTEXT_V2_SOURCE is defined (it > is defined in common.h). I've tested this case. Yes, of course. I have not stated anything different. > The manual claims: > The value of > argc must match the number of integer arguments passed to > func, otherwise the behavior is undefined. > (SunOS mion 5.9 Generic_112233-12 sun4u sparc SUNW,Ultra-250) > > I only pass single argument... Yes, but up to Solaris 8 it claimed: The integer value of argc must be one-greater-than the number of arguments that follow argc; otherwise, the behavior is undefined. For 5 arguments, the value of argc must be 6. AfaIk this would also hold for Solaris 9 without __MAKECONTEXT_V2_SOURCE, but this is deprecated. Btw, Solaris 9 and 10 can still handle binaries compiled under earlier versions.

1 0

Re: stunnel 4.14 and openssl 0.9.8a
by MeeAGhost 08 Nov '05

08 Nov '05

I am using stunnel to tunnel my VNC connection. As recent as version 4.12 I have been able to use the libeay32.dll and libssl32.dll files I created with openssl 0.9.X.X using Msys and Mingw with the steps below: 1. I comment out line 910 in the openssl Configure script 2. Create .def for dll's: perl util/mkdef.pl 32 libeay > ms/libeay32.def perl util/mkdef.pl 32 ssleay > ms/ssleay32.def 3. Execute the openssl configure script ./Configure mingw 4. Execute the make for openssl make 5. After the make completes I create the dlls dllwrap --dllname libeay32.dll --output-lib libeay32.a --def ms/libeay32.def libcrypto.a -lwsock32 -lgdi32 dllwrap --dllname libssl32.dll --output-lib libssl32.a --def ms/ssleay32.def libssl.a libeay32.a When I place the resulting dlls on the remote machine with version 4.14installed and establish a VNC connection to machine stunnel crashes and generates a Dr. Watson error. If I revert back to version 4.12 the dlls I created using the steps above --- everything works. If I install the 0.9.7idlls (which come as a part of the 4.14 Win Install package) everything works. I am trying to keep server and clients on the same version of openssl which is why I have been compling new dlls whenever I have upgraded the servers. Is there something unique being done in version 4.14 that prevents dlls created with 0.9.8a from being used? -- Chris

2 3

Solaris: new_context, makecontext
by Hans Werner Strube 08 Nov '05

08 Nov '05

Concerns all versions of sthreads.c using ucontext: As far as I know from the Solaris documentation and some experiments, the context treatment in new_context() is not universally correct. #if defined(__sgi) || (defined(__sparc) && !defined(HAVE___MAKECONTEXT_V2)) ctx->ctx.uc_stack.ss_sp=ctx->stack+STACK_SIZE-8; #else /* not an IRIX or old and buggy Solaris on Sparc */ ctx->ctx.uc_stack.ss_sp=ctx->stack; #endif The first case is wrong for Solaris 10, since HAVE___MAKECONTEXT_V2 is not defined there but the behavior is _always_ as with HAVE___MAKECONTEXT_V2 in Solaris 9 SPARC. (Solaris 9 SPARC behaves like Solaris 7 and 8 SPARC ["old and buggy"] if HAVE___MAKECONTEXT_V2 is not set, and like Solaris 10 if it is set.) In the "old and buggy" case, the third argument of makecontext() should be 2 instead of 1 (although the latter _may_ work). I do not know how this is in Solaris x86. At least, HAVE___MAKECONTEXT_V2 has no meaning there.

3 3

stunnel 4.14 released
by Michal Trojnara 03 Nov '05

03 Nov '05

The ChangeLog entry for stunnel 4.14: Version 4.14, 2005.11.02, urgency: HIGH: * Bugfixes - transfer() fixed to avoid random stalls introduced in version 4.12. - poll() error handing bug fixed. - Checking for dynamic loader libraries added again. - Default pidfile changed from $localstatedir/run/stunnel.pid to $localstatedir/stunnel/stunnel.pid. - Basic SSL library initalization moved to the beginning of execution. * Release notes - This is an important bugfix release. Upgrade is recommended. sha1sum for stunnel-4.14.tar.gz: b2edb3a2473367f2a9f04a877adcb332483a5267 Home page and download: http://stunnel.mirt.net/ Best regards, Mike

2 2

I: error=certificate signature failure
by Pulcini Maddalena 03 Nov '05

03 Nov '05

________________________________ Da: Pulcini Maddalena Inviato: gio 03/11/2005 8.58 A: stunnel Oggetto: I: error=certificate signature failure ________________________________ Da: Pulcini Maddalena Inviato: mer 02/11/2005 17.14 A: stunnel Oggetto: error=certificate signature failure Hi All, someone could help me to understand what happens and what my client needs to verify the peer? Thanks&Regards I configure stunnel in this way: stunnel.conf ================================ client = yes debug=7 cert = client69f.pem key = chiave69.pem cafile=cacert.pem verify = 1 capath= . [telnet] accept = 23 connect = 10.36.3.191:4433 ============================ I put all the files configured above in the same directory where stunnel-4.07.exe runs; I have a machine in which ssl server runs with a certificate signed by the same CA (cacert.pem). The log file is : ====================================== 2005.11.02 16:33:47 LOG5[1456:1084]: stunnel 4.07 on x86-pc-mingw32-gnu WIN32+IPv4 with OpenSSL 0.9.7f 22 Mar 2005 2005.11.02 16:33:47 LOG7[1456:1504]: Snagged 64 random bytes from C:/.rnd 2005.11.02 16:33:47 LOG7[1456:1504]: Wrote 1024 new random bytes to C:/.rnd 2005.11.02 16:33:47 LOG7[1456:1504]: RAND_status claims sufficient entropy for the PRNG 2005.11.02 16:33:47 LOG6[1456:1504]: PRNG seeded successfully 2005.11.02 16:33:47 LOG7[1456:1504]: Certificate: client69f.pem 2005.11.02 16:33:47 LOG7[1456:1504]: Key file: chiave69.pem 2005.11.02 16:33:47 LOG7[1456:1504]: Loaded verify certificates from cacert.pem 2005.11.02 16:33:47 LOG7[1456:1504]: Verify directory set to . 2005.11.02 16:33:47 LOG5[1456:1504]: No limit detected for the number of clients 2005.11.02 16:33:47 LOG7[1456:1504]: FD 156 in non-blocking mode 2005.11.02 16:33:47 LOG7[1456:1504]: SO_REUSEADDR option set on accept socket 2005.11.02 16:33:47 LOG7[1456:1504]: telnet bound to 0.0.0.0:23 2005.11.02 16:34:14 LOG7[1456:1504]: telnet accepted FD=168 from 127.0.0.1:2501 2005.11.02 16:34:14 LOG7[1456:1504]: FD 168 in non-blocking mode 2005.11.02 16:34:14 LOG7[1456:1504]: Creating a new thread 2005.11.02 16:34:14 LOG7[1456:1504]: New thread created 2005.11.02 16:34:14 LOG7[1456:1320]: telnet started 2005.11.02 16:34:14 LOG5[1456:1320]: telnet connected from 127.0.0.1:2501 2005.11.02 16:34:14 LOG7[1456:1320]: FD 192 in non-blocking mode 2005.11.02 16:34:14 LOG7[1456:1320]: telnet connecting 10.36.3.191:4433 2005.11.02 16:34:14 LOG7[1456:1320]: connect_wait: waiting 10 seconds 2005.11.02 16:34:14 LOG7[1456:1320]: connect_wait: connected 2005.11.02 16:34:14 LOG7[1456:1320]: Remote FD=192 initialized 2005.11.02 16:34:14 LOG7[1456:1320]: SSL state (connect): before/connect initialization 2005.11.02 16:34:14 LOG7[1456:1320]: SSL state (connect): SSLv3 write client hello A 2005.11.02 16:34:14 LOG7[1456:1320]: SSL state (connect): SSLv3 read server hello A 2005.11.02 16:34:14 LOG4[1456:1320]: VERIFY ERROR: depth=1, error=certificate signature failure: /C=Siena/O=amtec/OU=elsag/CN=CERTIFICATION AUTHORITY 2.0/description=CA CERTIFICATE/L=Abbadia San Salvatore 2005.11.02 16:34:14 LOG7[1456:1320]: SSL alert (write): fatal: handshake failure 2005.11.02 16:34:14 LOG3[1456:1320]: error stack: 14090086 : error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed 2005.11.02 16:34:14 LOG3[1456:1320]: error stack: D089006 : error:0D089006:asn1 encoding routines:ASN1_verify:EVP lib 2005.11.02 16:34:14 LOG3[1456:1320]: SSL_connect: 4077068: error:04077068:rsa routines:RSA_verify:bad signature 2005.11.02 16:34:14 LOG7[1456:1320]: telnet finished (0 left)

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

stunnel-users November 2005