|
Stunnel FAQ: Troubleshooting
Chapter Contents:
This section gives you very basic information on how to troubleshoot Stunnel.
-
Stunnel has many
#ifdef statements to make it portable
to many systems, including some involving the *printf() commands.
This makes FormatGuard very unhappy. Currently your only option
is to not compile with FormatGuard. Stunnel does it's string
manipulation and syslogging with safe functions
to protect against overflows and format string bugs.
You're welcome to do a source code audit, of course, as others,
myself included, have.
-
Solution: The first posibility is that
you haven't installed an SSL library, either OpenSSL or SSLeay.
In that case you should download and compile one of them.
OpenSSL can be found at www.openssl.org.
The other possibility is that you installed your SSL library
in a non-standard place. Use the --with-ssl
directive when running configure to tell it where this
directory is.
Note this is the directory in which you have a certs
subdirectory, and the SSL libraries. If your certs directory is not
inside your SSL library directory, then you must make a link to the
certs directory inside your SSL directory.
-
"I get the following error when I try to compile Stunnel:"
ssl.c: In function `context_init':
ssl.c:205: too few arguments to function
`PEM_read_bio_DHparams'
Solution:
You are probably using one of the older versions of Stunnel (3.4a and earlier)
You can either upgrade to a newer version which has better OpenSSL support,
or do the following:
OpenSSL 0.9.4 changed the parameters
sent to the PEM_read_bio_DHparams function. You can apply a
patch contributed by Mark D. Baushke:
To use it, save the
patch into a file called
'stunnel-openssl.patch'
in the directory in which you unpacked Stunnel. Then run the command
patch < stunnel-openssl.patch
and recompile Stunnel.
If you do not have (or feel comfortable with) patch, you could
simply change line 205 of ssl.c from
if(!(dh=PEM_read_bio_DHparams(bio, NULL, NULL))) {
to
if(!(dh=PEM_read_bio_DHparams(bio, NULL, NULL, NULL))) {
The patch above is much more portable however.
-
When I try to compile I get errors like the following:
gcc -g -O2 -Wall -I/usr/include
-Dlibdir=\"/usr/local/lib\" -c ssl.c
ssl.c:83: lhash.h: No such file or directory
ssl.c:84: ssl.h: No such file or directory
ssl.c:85: err.h: No such file or directory
Solution:
The distribution currently has a bug where it may not find your
SSL directories. This will be fixed in an upcoming version.
If you have SSL configured in a non-standard place, use
this configure script instead
of the one that comes with Stunnel. It adds a flag
'--with-ssl=PATH'
to specify the actual locations of your ssl installation.
-
Solution: You probably have it in a non-standard place,
ie somewhere that gcc can't find it on it's own.
Let's say you had your tcp wrappers installed in /opt/tcpd_7.6.
To help gcc find your include files and libraries, you'd want to set three
environment variables as follows:
CFLAGS="$CFLAGS -I/opt/tcpd_7.6/include"
CPPFLAGS="$CPPFLAGS -I/opt/tcpd_7.6/include"
LDFLAGS="$LDFLAGS -L/opt/tcpd_7.6/lib"
export CFLAGS CPPFLAGS LDFLAGS
And then re-run configure. This is the generic way
to have configure find specific libraries, and is not
specific to Stunnel itself.
-
Your browser (bet you're using netscape) is being helpful
and gunzipping it for you, but is leaving the .gz extension,
and you probably have the uncompressed tar archive with a
misleading name. Try untaring it directly.
Firstly, the most important things to try when you're having trouble
running Stunnel is to:
- run with full debug mode
-D 7
- if running the daemon, run it in the foreground
-f
Doing this gives you the best chance of catching the errors in the
log on the screen.
If you don't have the openssl program (for example you're using the
precompiled version of Stunnel on a Windows machine) then you need
to generate an stunnel.pem file in some other manner. You can
find a spare unix workstation that does have openssl installed, for
example.
If you still can't get your hands on a machine with openssl installed,
you can generate a certificate using the stunnel.org server by
going to http://www.stunnel.org/pem/.
-
You are probably missing the
[service] definition in your config. For
example
pid = /stunnel.pid
setuid = nobody
setgid = nobody
debug = local6.err
foreground = no
client = yes
[mysyslog]
accept = localhost:syslog
connect = logging:syslogs
Without that [mysyslog] line, Stunnel 4.x assumes you
want to operate in inetd-style mode. (See Running
Stunnel for more info.)
-
Per Christian Seberino, remove the hwcrypto RPM and all
should fix itself.
-
I get the error
stunnel[PID]: Wrong permissions on /path/to/stunnel.pem
on my Stunnel server or on Stunnel client using client-side
certificates. What's wrong?
Answer:
The stunnel.pem file contains your key (private data) and
certificate (public data). In order for Stunnel to start
automatically without requiring a password, the key is created
without a password. This means that anyone who can read
this file can compromise your SSL security. This file must
be readable only by root, or the user who runs Stunnel.
Use the chmod command to fix permissions on this file, ala
chmod 600 /path/to/stunnel.pem
-
I get the error
SSL_accept: error:00000000::lib(0) :func(0) :reason(0)
What does it mean?
Answer:
That error means that your client has closed the connection
before SSL was negotiated. That probably means that you're
trying to connect to your Stunnel daemon with a non-SSL
client. Make sure you are using SSL on your client.
-
I just can't get ftp to work over Stunnel no matter how hard I try.
Answer:
Stunnel cannot be used for the FTP daemon because of the nature of
the FTP
protocol which utilizes multiple ports for data transfers. There are
SSL aware FTP servers available.
Alternitively you could use a different protocol. All versions
of SSH include a program called scp which works
like rcp. Recent versions of OpenSSH include a program
called sftp which has an ftp-like feel.
-
Try installing the High Encryption Pack and all other service packs
-- this may be the problem.
-
The error looks like the following:
SSL_accept:error:140760F8:SSL
routines:SSL23_GET_CLIENT_HELLO:unknown protocol
SSL_accept:error:1409B0AB:SSL
routines:SSL3_SEND_SERVER_KEY_EXCHANGE:missing
tmp rsa key
Solution:
One day after the official release of Windows 2000 a number of
'Critical Updates' were released. At least one of them fixes the
problem, probably the "128bit encryption pack update".
It is not determined if this applies to merely Outlook, or Windows 2000
in general, however it's a good idea to update your machine.
-
To use POP with SSL in Outlook (tested with 2000, 98, and
Outlook Express, should work with other versions), simply
select the checkbox under the 'Incoming mail (POP3)' section
that says 'This server requires a secure connection (SSL).
This is all located on the advanced tab in the account
properties. Make sure that the port it changes to when you
check the box is correct (should be 995 by default) and
you should be golden.
Submitted by Green Onyx <lists@greenonyx.com>
-
Solution: The version of OpenSSL with which the pre-compiled
Stunnel binary was made did not support reading in from standard in,
thus if you want to use Stunnel in client mode in a way such as
stunnel -c -r www:443 then it will not work.
OpenSSL 0.9.5 and newer claim it supports this now. If anyone
can try and report back that would be wonderful.
-
Solution: Stunnel has a bug in versions up to 3.8. It
didn't correctly attempt to set the SessionID, and thus never
used it when it should have been available. Try using
this patch) to ssl.c.
This patch was integrated in 3.8p1 and later.
-
Solution Download Stunnel 3.8p1 or later,
or apply the patch for this problem available from
the stunnel.org
patch library
The problem stems from the fact that
as of OpenSSL 0.9.5, the underlying SSL libraries
require that the cryptographic algorithms have their random number
generator seeded with random information. See
http://www.openssl.org/support/faq.html#USER1 for the
explanation.
All versions from 3.8p1 on have this bug fixed. Prior to that
it only affected operating systems without a
/dev/urandom device.
-
You are likely not on a system that has /dev/urandom, and OpenSSL is
not able to gather enough entropy to create strong SSL sessions.
Option include, in rough order of preference:
- Use PRNGd (Portable Random Number Generator Daemon) available here. This is an EGD compatible random number generator. It gathers
entropy from system commands and feeds them to the OpenSSL RNG,
and thus will never block waiting for more random data. Point to your
PRNGd socket with the '
-E /path/to/sock' argument to Stunnel.
- Use EGD (Entropy Gathering Daemon) available here. EGD was the first
widely used RNG that got it's entropy from system commands.
Unfortunately EGD can block (ie hang) until it gathers enough
entropy. (For this reason PRNGd is prefered over EGD.)
Point to your EGD socket with the '
-E /path/to/sock' argument
to Stunnel.
- If you are running Solaris, snag the SUNWski patch, which will
create /dev/random for you. Simply '
ln -s random
/dev/urandom'
and OpenSSL (and thus Stunnel) will find entropy for you
automatically.
This patch has been reported to be available as part of
the following patches, YMMV: 105710-01, 106754-01,
106755-01, 106756-01.
On Solaris 8 you could install patch 112438 to get /dev/random and
/dev/urandom devices.
- In the worst case you can create a file or files
with random data (for example copy sections of your
running kernel to a file) and use them to seed the
data. See the Stunnel manual page 'RANDOMNESS'
section for the full list of which files are searched
and in which order. It is important to remember that these
random datafiles may be overwritten unless the -W flag is
used!
-
See the transparent mode issues
page.
-
When I try to use pop with Outlook I get the following
error:
Unable to logon to the server using Secure Password
Authentication. Account: 'example.net', Server:
'mail.example.net', Protocol: POP3,
Server Response: '.', Port: 995,
Secure(SSL): Yes, Error Number: 0x800CCC18
You told Outlook to use Secure Password Authentication,
but your POP server doesn't support it. Since you're using
Stunnel, your password is not ever in the clear anyway,
so you can just turn off Secure Password Authentication.
If you find you are getting zombie processes (those that have
been created by Stunnel and end up in a <defunct> state
that never get cleaned up) then you should upgrade to Stunnel
3.14 or later. Zombie problems seem to have been solidly fixed by then.
Note that many SSL clients will keep open a connection, and thus
a process that is still lingering may be there simply because it's
still in use. POP and IMAP commonly stick around after mail has
been gathered, even though you don't notice activity.
Linux threads have entries in the process table. A threaded
Stunnel daemon will have n+1 entries in /proc, where n is
the number of current threads. It's not an error.
If you have arguments against this way of implementing
threads, talk to Linus. Linux threads are damned fast
as they are, so you're not likely to convince him to
change things.
You're probably using an older version of Stunnel, before 3.16.
Try an upgrade and you'll probably be much happier.
If you want to stick with one of the older versions,
there are a few other options.
If you're just trying to snag a https:// web page, for
example, all you really need to do is use the openssl program itself,
such as:
$ openssl s_client -connect www:443 -quiet 2>/dev/null <<EOM
GET /blah.html HTTP/1.0
EOM
Which should do the trick. Alternatively, you could apply the
stdout patch by Markus Foerster in the patches
directory.
(Submitted by Leon Harris )
Problem:
"After I start the tunnel on the server, and then start the tunnel on
the client, all is well. However, after I close that first MySQL client
connection, I cannot start another. Tcpdump reveals that the client is
passing no packets to the server."
server$ stunnel -d 3307 -r localhost:3306
client$ stunnel -c -d 3306 -r 192.168.1.2:3307
Solution:
The problem below is caused by proplems with linux kernel 2.2.14 and
MySQL. Some of the networking code appears to be a bit dodgy. This
is fixed in 2.2.16.
The fix? Upgrade your kernel past 2.2.14. 2.2.16 works for me.
PS, I am indebted to the post by Sergey Yegorov to
mailing.database.mysql who had a related problem with the mysqld
server, and who wrote a detailed enough message to be let me
recognise this similar problem with the mysql client.
Some OSs only allow a certain number
of program arguments in the inetd.conf line. Solaris only
allows 5, for example. Your best options include:
- Joining flags that take options (such as
'
-l/usr/sbin/in.telnetd' instead of
'-l /usr/sbin/in.telnetd') to concerve
inetd arguments, or
- create a shell script that runs your Stunnel program
with the correct arguments and have
inetd launch
that script instead of stunnel directly.
-
Solution: You probably have TCP Wrapper support compiled
into Stunnel, and are having DNS problems. TCP Wrappers do reverse
lookups of the incoming IP address. If you have a bad server
in
/etc/resolv.conf and this query fails then
it'll take time before the resolver will go to the next one,
and Stunnel will wait. We suggest any or all of the following:
- Fix your /etc/resolv.conf
- Make sure your machines have reverse DNS entries. It's
just a good practice anyway.
- Try accessing a closer name server first in your resolv.conf
- Consider running a caching nameserver on your local host
and pointing to it first
If the problem doesn't go away, you may want to try compiling
Stunnel without TCP Wrappers and see if the problem is still
there and troubleshoot further.
-
Sulution:This is an OS-dependent issue. You probably have
a hard limit of the number of file descriptors that can be open by
processes. Increase this number to a more acceptable level. Stunnel
may use anywhere from one to four file descriptors per
connection depending on how you're using it.
For a quick glance at how to change this parameter on
Solaris, go here.
-
One option might be to turn on the TCP NODELAY option on
both ends. On the server, include the following options:
-O l:TCP_NODELAY=1
and on the client include
-O r:TCP_NODELAY=1
-
Per Mike:
It's a well known problem with Internet Explorer and several other
products. They don't send close_notify message before TCP FIN
packet violating SSLv3 and TLSv1 protocols. It is also
a security problem: Microsoft applications are vulnerable to
truncation attacks. Is Microsoft able to implement anything
properly?
Currently stunnel implements ugly 10-seconds timeout to work
with Microsoft... I hate it, but several peple need it.
See RFC 2246 chapter 7.2.1. for details.
-
From Mike:
How can I increase the number of file descriptors per process in
Solaris?
In 2.3 in earlier this requires poking the kernel. In Solaris 2.4+,
this can be accomplished by adding the following lines to /etc/system:
* set hard limit on file descriptors
set rlim_fd_max = 4096
* set soft limit on file descriptors
set rlim_fd_cur = 1024
Raising the soft limit past 256 may confuse certain applications,
especially BCP applications. Raising the limit past 1024 may
confuse applications that use select(). Select() cannot use more
than 1024 file descriptors at this time prior to Solaris 7. In
Solaris 2.6, the RPC code was rewritten to use poll(), which
does work with many more fds than select(). Prior to 2.6, all
RPC servers will likely crash and burn if you increase the
fd soft limit past 1024.
Solaris 7 allows upto 65536 fds passed to select; this is the
default for 64 bit applications but it requires recompiling with
a larger value for FD_SETSIZE for 32 bit apps.
Change FD_SETSIZE value in your system headers (select.h) to
whatever value you consider safe and rebuild
Stunnel (make clean; make; make install).
-Mike
From Franz Glasner:
> I am running stunnel on solaris 8. I want to increase the maximum of
> clients allowed above 500. I already changed in /etc/system set
> rlim_fd_max = 8192 and set rlim_fd_cur = 4096. But I don't get above
> 500. I think the limiting factor is FD_SETSIZE. I don't know how to
> change that. Can anyone help me?
This is to be done at compile time.
Add the compiler option
-DFD_SETSIZE=4096
and compile stunnel again.
Franz.
-
Victor Danilchenko found that logs for Stunnel were correctly
going to mail.log, as he'd configured, but then started
going to user.log after new threads were created, and believes
that the syslog functions in Digital Unix 4.0d aren't thread
safe. He created a
patch that
can fix this problem.
-
If you get errors that look like this:
bind: Unknown error (10049)
and don't know offhand what error 10049 is (for example) then you
can blame M$ for not providing helpful error text such as is
available with perror() on Unix systems. However you can check
http://www.sockets.com/err_lst1.htm which has a list
of common error codes.
-
If you are using Stunnel in a chroot environment, you'll need
to include the /etc/hosts.allow and /etc/hosts.deny files
within that environment. So say your stunnel.conf had the
following:
chroot = /path/to/chroot/
Then you'd need to create /path/to/chroot/etc and put your
hosts.allow and hosts.deny files there:
mkdir /path/to/chroot/etc
cp /etc/hosts.allow /etc/hosts.deny /path/to/chroot/etc
Make sure that you change these files, not the global
/etc/hosts.{allow.deny} files.
-
If you get the following error message in Stunnel:
2003.01.18 17:46:07 LOG3[6093:32770]: SSL_accept: 1407609C:
error:1407609C:SSL routines:SSL23_GET_CLIENT_HELLO:http request
then you have Stunnel running as a daemon mode, not client mode (no -c for 3.x,
or you have client=no for 4.x) and your web browser
is connecting to it as if it's a normal webserver, ala http://example.com/.
If Stunnel is supposed to be running as a client, then fix your commandline
args or stunnel.conf. If you do mean to be running as a daemon
(SSL server) then point your browser at https://host:port/ instead of http://host:port/
-
First of all, why are you doing this instead of just
using OpenSSH
which is much better anyway???
Petr Vandrovec notes that
we had to start telnetd with 'telnetd -a' on our AIXes if we feed
data to it through stunnel. For some strange reason AIX's telnet daemon
just decides to throw data away if you do not read them quickly enough -
for example cat-ting 20MB file full of zeroes was transfered as 5MB
of zeroes to client. And no, it is not caused by stunnel, but by 4.3.2
telnetd.
Eric Eberhard suggests uning including -R as an alternate
solution.
-
Dave Gardner suggests the following:
It's a timing error in Eudora, not a problem in stunnel. In Eudora, go
to "Tools" -> "Options". Scroll down and select "Advanced Network".
Increase the "Network Buffer Size" to 8192. Put a check mark in "Cache
network info". If you want to increase "Network open timeout" and
"Network timeout after" values too, it wouldn't hurt (try 1000). Then
try to collect email again. Should work for you.
And Frank Notspak reports success setting "Network Buffer Size"
to 32000.
You might also want to try including
options = DONT_INSERT_EMPTY_FRAGMENTS
in your stunnel.conf.
-
Remove the following code from stunnel.c (located in
CtrlHandler(DWORD fdwCtrlType)) and recompile
case CTRL_LOGOFF_EVENT:
log(LOG_NOTICE, "Process exit: user logoff");
break;
|
