There's an example of rsync over stunnel at
http://www.stunnel.org/examples/rsync_mike.html
but it appears to be using stunnel 3 syntax. Has anyone
successfully made this work using stunnel 4?
right now /etc/stunnel.conf is same on client and server, has
[rsync]
accept = 2222
connect = 873
Steve Timm
------------------------------------------------------------------
Steven C. Timm, Ph.D (630) 840-8525 timm(a)fnal.gov http://home.fnal.gov/~timm/
Fermilab Computing Div/Core Support Services Dept./Scientific Computing Section
Assistant Group Leader, Farms and Clustered Systems Group
Lead of Computing Farms Team
When I start stunnel 4.05, I am presented with a dialog that requests
that I enter a pass phrase in order to access our private key. Is there
anyway to bypass this dialog. I would like to add the pass phrase to the
config file, so that the dialog isn't presented. Security isn't an
issue. Our config file will be in a secure location. Otherwise, our
operations people are going the have to know the pass phrase to start
stunnel.
Thanks for your help.
John
----------------------------------------------
John Bradley
Software Development
Lava Trading Inc.
95 Morton Street, 4th Floor
New York, NY 10014
Tel: 212.609.0162
Fax: 212.609.0101
www.lavatrading.com <http://www.lavatrading.com/>
This communication (including attachments) contains information that may
be confidential. It is for the exclusive use of the intended
recipient(s). If you are not the intended recipient(s), please note that
any distribution, copying or use of this communication or the
information in it (including, in any attachments) is strictly
prohibited. If you have received this communication in error please
notify us by e-mail or by telephone 212-609-0162 and then delete the
e-mail and all attachments and any copies thereof.
I'm running stunnel 3.xx with thttpd (an embedded http server) on a small
embedded machine on a pci card running linux. Establishing ssh, ftp, and http
connections and using OpenSSL has all worked fine since they've been
installed. I've been experiencing a strange issue. It seems that stunnel
fails (somehow) to inform https clients that the connection has been closed.
The sequence of events that I'm observing goes like this:
T+0.0s: https client initiates request on port 443 (https).
T+0.1s: stunnel establishes connection with thttpd on port 80.
T+0.4s: thttpd finishes and dies, closing connection with stunnel.
T+0.5s: stunnel finishes sending thttpd's output to its client, and then
stops, believing that it has finished that connection. If forked,
this copy of stunnel dies. The client (internet explorer, firefox,
mozilla... doesn't matter) still believes that the connection is
active, and waits for additional data.
T+10.5s: Roughly 10 seconds later the client decides that the server timed
out
and displays what has been sent so far, which is the entire page.
The only visible symptom is that small webpages seem to take 10
seconds
to load.
The visible symptom, then, is that webpages below a certain size (where that
size is determined by the browser's willingness to refresh its view as data
is being sent) take about 10 seconds to load.
Is it possible that this behavior is due to stunnel?
_______________________________
Do you Yahoo!?
Express yourself with Y! Messenger! Free. Download now.
http://messenger.yahoo.com
hello,
i am using stunnel4.x under linux
in my server i set verify option level 3
and in my clinet i added stunnel.pem
so verify can happen
now can my isp knows my key of encrytion
and decrypt ?
so it is safe to set verify level 3 ? or it shouldnot ?
can my isp decrpt my traffic or knows what sites i visted?
thanks
With stunnel-4.x, it would be greatly desirable to make the option "verify"
(and possibly the related certs) in stunnel.conf service-dependent rather
than global. I have not looked at the code sufficiently to determine whether
and how this could be possible.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Michal Trojnara wrote:
|
| What about using my stunnel3 script instead?
|
| BTW: I really would like to know your comments on this script.
| Does anyone need stunnel 3.x, now?
|
Unfortunately we will have to keep stunnel 3.x for some time (probably at least
until next summer), due to a large distributed installation.
I appreciate to have the wrapper script to migrate the current installations.
If this was available when stunnel 4 was released we probably would have it in
our installations right now...
Anyone to verify my patch for stunnel-3.26?
Best regards,
Martin.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3-nr1 (Windows XP)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFBRU5SnNbgBz1XxU4RAspgAJ9akmjZNTOig+YW69nRUCDX/hfTFwCfSwqL
TKb3reUiIdYwVntSZSgQVgg=
=wb9x
-----END PGP SIGNATURE-----
Hello everybody,
I recompiled the newest "traditional" versions of OpenSSL and stunnel on
Solaris, Linux, and HPUX. None of the defaults were changed except for
--prefix and --openssldir/--with-ssl and --install_prefix
Simple tests went through without problems on Linux and HPUX. For Solaris I
have a big problem.
Any help is appreciated, for example a trustworthy Stunnel-3.26 binary
statically linked with OpenSSL 0.9.6m for Solaris 2.6 could also help.
Summary
=======
Stunnel listens on host medusa 12480 for SSL and forwards plain HTTP to
apache on another host (sirius). When I try a HTTPS request to medusa:12480
using a browser or wget, the connection is broken immediately.
When stunnel runs under the system call tracer truss the same commands
succeed most of the time. In the truss output one can see an EAGAIN on the
-r socket of stunnel. That might indicate that there is a problem when TCP
buffers do not fill quickly receiving on the -r side.
Details
=======
Client side:
(IP is 192.168.50.153)
C:\>wget --spider https://medusa:12480
--12:59:18-- https://medusa:12480/
=> `index.html'
Resolving medusa... 192.168.41.13
Connecting to medusa[192.168.41.13]:12480... connected.
Unable to establish SSL connection.
Unable to establish SSL connection.
Stunnel side:
[mkn@medusa] stunnel-3.26 721$ ./stunnel -p ./stunnel.pem -D 7 -d 12480 -r
sirius:80 -f -Pnone
2004.09.08 13:06:52 LOG5[29399:1]: Using 'sirius.80' as tcpwrapper service
name
2004.09.08 13:06:52 LOG4[29399:1]: Wrong permissions on ./stunnel.pem
2004.09.08 13:06:52 LOG7[29399:1]: Snagged 64 random bytes from
/nfss/home/mkn/.rnd
2004.09.08 13:06:53 LOG7[29399:1]: Wrote 1024 new random bytes to
/nfss/home/mkn/.rnd
2004.09.08 13:06:53 LOG7[29399:1]: RAND_status claims sufficient entropy for
the PRNG
2004.09.08 13:06:53 LOG6[29399:1]: PRNG seeded successfully
2004.09.08 13:06:53 LOG7[29399:1]: Certificate: ./stunnel.pem
2004.09.08 13:06:53 LOG5[29399:1]: stunnel 3.26 on sparc-sun-solaris2.6
PTHREAD+LIBWRAP with OpenSSL 0.9.6m 17 Mar 2004
2004.09.08 13:06:53 LOG7[29399:1]: No pid file being created
2004.09.08 13:06:53 LOG5[29399:1]: FD_SETSIZE=1024, file ulimit=64 -> 28
clients allowed
2004.09.08 13:06:53 LOG7[29399:1]: SO_REUSEADDR option set on accept socket
2004.09.08 13:06:53 LOG7[29399:1]: sirius.80 bound to 0.0.0.0:12480
2004.09.08 13:06:56 LOG7[29399:1]: sirius.80 accepted FD=7 from
192.168.50.153:1937
2004.09.08 13:06:56 LOG7[29399:4]: sirius.80 started
2004.09.08 13:06:56 LOG5[29399:4]: sirius.80 connected from
192.168.50.153:1937
2004.09.08 13:06:56 LOG7[29399:4]: sirius.80 connecting 192.168.41.223:80
2004.09.08 13:06:56 LOG7[29399:4]: Remote FD=9 initialized
2004.09.08 13:06:56 LOG7[29399:4]: Stunnel manual RSA blinding enabled
2004.09.08 13:06:56 LOG7[29399:4]: SSL state (accept): before/accept
initialization
2004.09.08 13:06:56 LOG7[29399:4]: SSL state (accept): SSLv3 read client
hello A
2004.09.08 13:06:56 LOG7[29399:4]: SSL state (accept): SSLv3 write server
hello A
2004.09.08 13:06:56 LOG7[29399:4]: SSL state (accept): SSLv3 write
certificate A
2004.09.08 13:06:56 LOG7[29399:4]: SSL state (accept): SSLv3 write server
done A
2004.09.08 13:06:56 LOG7[29399:4]: SSL state (accept): SSLv3 flush data
2004.09.08 13:06:56 LOG3[29399:4]: SSL_accept: Peer suddenly disconnected
2004.09.08 13:06:56 LOG7[29399:4]: sirius.80 finished (0 left)
[mkn@medusa] stunnel-3.26 722$ ./stunnel -V
stunnel 3.26 on sparc-sun-solaris2.6 PTHREAD+LIBWRAP with OpenSSL 0.9.6m 17
Mar 2004
Default behaviour:
run in inetd mode (unless -d used)
run in background (unless -f used)
run in ssl server mode (unless -c used)
Compile time defaults:
-v level no verify
-a directory (none)
-A file (none)
-S sources 2
-t timeout 300 seconds
-B bytes 64
-D level 5
-P pid dir /opt/stunnel/var/stunnel/
-p pemfile in server mode: stunnel.pem
in client mode: none
Socket option defaults:
Option Accept Local Remote OS default
SO_DEBUG -- -- -- 0
SO_DONTROUTE -- -- -- 0
SO_KEEPALIVE -- -- -- 0
SO_LINGER -- -- -- 0:0
SO_OOBINLINE -- -- -- 0
SO_RCVBUF -- -- -- 8192
SO_SNDBUF -- -- -- 8192
SO_RCVLOWAT -- -- -- --
SO_SNDLOWAT -- -- -- --
SO_RCVTIMEO -- -- -- --
SO_SNDTIMEO -- -- -- --
SO_REUSEADDR 1 -- -- 0
IP_TOS -- -- -- 0
IP_TTL -- -- -- 255
TCP_NODELAY -- -- -- 0
[mkn@medusa] stunnel-3.26 724$ uname -a
SunOS medusa 5.6 Generic_105181-39 sun4u sparc SUNW,Ultra-Enterprise
[mkn@medusa] stunnel-3.26 726$ gcc -v
Reading specs from /usr/local/lib/gcc-lib/sparc-sun-solaris2.6/2.95.2/specs
gcc version 2.95.2 19991024 (release)
When running the same stunnel under truss, I sometimes have success in
retrieving the document, but sometimes I get:
(...initialisation omitted...)
poll(0xEFFFD4E0, 2, -1) = 1
fcntl(7, F_GETFL, 0x00000000) = 2
fstat64(7, 0xEFFFF3D8) = 0
getsockopt(7, 65535, 8192, 0xEFFFF4DC, 0xEFFFF4D4) = 0
fstat64(7, 0xEFFFF3D8) = 0
getsockopt(7, 65535, 8192, 0xEFFFF4DC, 0xEFFFF4D8) = 0
setsockopt(7, 65535, 8192, 0xEFFFF4DC, 4) = 0
fcntl(7, F_SETFL, 0x00000082) = 0
accept(7, 0xEFFFF5D0, 0xEFFFF548) = 8
fstat64(7, 0xEFFFF3D8) = 0
getsockopt(7, 65535, 8192, 0xEFFFF4DC, 0xEFFFF4D8) = 0
setsockopt(7, 65535, 8192, 0xEFFFF4DC, 4) = 0
fcntl(7, F_SETFL, 0x00000002) = 0
time() = 1094642471
getpid() = 2339 [2337]
write(4, 0x000E763C, 83) = 83
2 0 0 4 . 0 9 . 0 8 1 3 : 2 1 : 1 1 L O G 7 [ 2 3 3 9 : 1 ]
: s i r i u s . 8 0 a c c e p t e d F D = 8 f r o m 1
9 2 . 1 6 8 . 5 0 . 1 5 3 : 2 7 6 3\n
fcntl(8, F_SETFD, 0x00000001) = 0
lwp_cond_signal(0xEF66B278) = 0
lwp_cond_wait(0xEF66B278, 0xEF66B288, 0xEF565C48) = 0
lwp_self() = 3
time() = 1094642471
getpid() = 2339 [2337]
write(4, 0x000E763C, 52) = 52
2 0 0 4 . 0 9 . 0 8 1 3 : 2 1 : 1 1 L O G 7 [ 2 3 3 9 : 4 ]
: s i r i u s . 8 0 s t a r t e d\n
brk(0x000F73A8) = 0
brk(0x000FF3A8) = 0
getpeername(8, 0x000F56C4, 0xEF20BC78) = 0
getpid() = 2339 [2337]
getpeername(8, 0x000DF2E0, 0xEF20B44C) = 0
getsockname(8, 0x000DF2F0, 0xEF20B44C) = 0
open("/etc/hosts.allow", O_RDONLY) Err#2 ENOENT
getpid() = 2339 [2337]
open("/proc/2339/psinfo", O_RDONLY) = 9
read(9, "\f\0 F H\0\0\005\0\0\t #".., 336) = 336
close(9) = 0
fstat(-1, 0xEF209E40) Err#9 EBADF
open("/dev/conslog", O_WRONLY) = 9
fcntl(9, F_SETFD, 0x00000001) = 0
fstat(9, 0xEF209E40) = 0
fstat(9, 0xEF20A8A0) = 0
time() = 1094642471
getpid() = 2339 [2337]
putmsg(9, 0xEF209F58, 0xEF209F4C, 0) = 0
open("/etc/.syslog_door", O_RDONLY) = 10
door_info(10, 0xEF209E90) = 0
getpid() = 2339 [2337]
door_call(10, 0xEF209E78) = 0
close(10) = 0
open("/etc/hosts.deny", O_RDONLY) Err#2 ENOENT
fstat(9, 0xEF20A8A0) = 0
time() = 1094642471
getpid() = 2339 [2337]
putmsg(9, 0xEF209F58, 0xEF209F4C, 0) = 0
open("/etc/.syslog_door", O_RDONLY) = 10
door_info(10, 0xEF209E90) = 0
getpid() = 2339 [2337]
door_call(10, 0xEF209E78) = 0
close(10) = 0
time() = 1094642471
getpid() = 2339 [2337]
write(4, 0x000E763C, 79) = 79
2 0 0 4 . 0 9 . 0 8 1 3 : 2 1 : 1 1 L O G 5 [ 2 3 3 9 : 4 ]
: s i r i u s . 8 0 c o n n e c t e d f r o m 1 9 2 . 1
6 8 . 5 0 . 1 5 3 : 2 7 6 3\n
so_socket(2, 2, 0, "", 1) = 10
time() = 1094642471
getpid() = 2339 [2337]
write(4, 0x000E763C, 73) = 73
2 0 0 4 . 0 9 . 0 8 1 3 : 2 1 : 1 1 L O G 7 [ 2 3 3 9 : 4 ]
: s i r i u s . 8 0 c o n n e c t i n g 1 9 2 . 1 6 8 . 4
1 . 2 2 3 : 8 0\n
connect(10, 0xEF20BC00, 16) = 0
time() = 1094642471
getpid() = 2339 [2337]
write(4, 0x000E763C, 59) = 59
2 0 0 4 . 0 9 . 0 8 1 3 : 2 1 : 1 1 L O G 7 [ 2 3 3 9 : 4 ]
: R e m o t e F D = 1 0 i n i t i a l i z e d\n
time() = 1094642471
getpid() = 2339 [2337]
time() = 1094642471
getpid() = 2339 [2337]
write(4, 0x000E763C, 70) = 70
2 0 0 4 . 0 9 . 0 8 1 3 : 2 1 : 1 1 L O G 7 [ 2 3 3 9 : 4 ]
: S t u n n e l m a n u a l R S A b l i n d i n g e n
a b l e d\n
time() = 1094642471
brk(0x000FF3A8) = 0
brk(0x001033A8) = 0
time() = 1094642471
getpid() = 2339 [2337]
write(4, 0x000E763C, 83) = 83
2 0 0 4 . 0 9 . 0 8 1 3 : 2 1 : 1 1 L O G 7 [ 2 3 3 9 : 4 ]
: S S L s t a t e ( a c c e p t ) : b e f o r e / a c c
e p t i n i t i a l i z a t i o n\n
brk(0x001033A8) = 0
brk(0x001093A8) = 0
brk(0x001093A8) = 0
brk(0x0010D3A8) = 0
read(8, 0x00102C78, 11) Err#11 EAGAIN
time() = 1094642471
getpid() = 2339 [2337]
write(4, 0x000E763C, 73) = 73
2 0 0 4 . 0 9 . 0 8 1 3 : 2 1 : 1 1 L O G 3 [ 2 3 3 9 : 4 ]
: S S L _ a c c e p t : P e e r s u d d e n l y d i s c
o n n e c t e d\n
setsockopt(10, 65535, 128, 0xEF20BC78, 8) = 0
close(10) = 0
setsockopt(8, 65535, 128, 0xEF20BC78, 8) = 0
close(8) = 0
time() = 1094642471
getpid() = 2339 [2337]
write(4, 0x000E763C, 62) = 62
2 0 0 4 . 0 9 . 0 8 1 3 : 2 1 : 1 1 L O G 7 [ 2 3 3 9 : 4 ]
: s i r i u s . 8 0 f i n i s h e d ( 0 l e f t )\n
lwp_cond_signal(0xEF66B278) = 0
lwp_cond_wait(0xEF66B278, 0xEF66B288, 0xEF543CA0) = 0
lwp_mutex_unlock(0xEF66B288) = 0
lwp_mutex_lock(0xEF66B288) = 0
time() = 1094642471
lwp_mutex_lock(0xEF66B288) = 0
lwp_cond_broadcast(0xEF670F50) = 0
poll(0xEFFFD4E0, 2, -1) (sleeping...)
With kind regards,
Martin Kneissl
_________________________
Atos Worldline GmbH
CRM and Telco
Pascalstrasse 19
52076 Aachen
Germany
Phone: +49 (0) 2408 148 173
Fax: +49 (0) 2408 148 204
mailto:[email protected]www.atosworldline.de
hello,
when i run stunnel4.x under linux
it gaves statment Unable to open "/dev/cryptonet"
but it run normal ..
what this error mean ?
does it means stunnel is running but not encrypting ?
and is there any problem running stunnel without "/dev/cryptonet ?
secand question
i have stunnel4.x running with verify 3 option
can my isp read data between me and the other host ..
if i am transmiting data through stunnel ?
thanks.
Correcting my previous post,
> ... one can see an EAGAIN on the -r socket of stunnel.
That's not true, the EAGAIN is on the accepted file descriptor.
The problem is not solved, though ...
Martin.