86b2e895f2
maintained. In fact, it does not have two annoying bugs of the v4: stunnel processes do not stick around forever, and the cli options are still present as opposed to the v4 windows-like config file. From the changelog since v3.22 (when the pkgsrc stunnel was upgraded to 4.0.4): Version 3.26, 2003.08.29 urgency: MEDIUM: * Several improvements, all implemented by Steve Grubb: * Fixed new child signal handler, introduced in 3.25, which was buggy in pthreads environments * Fixed problem where the accept() can block indefinately if the user or OS has discarded the connection. * Minor code cleanup and removal of duplicate function. Version 3.25, 2003.07.25, urgency: HIGH: * Fixed buggy SIGCHLD handling using patch supplied by Nalin Dahyabhai of Red Hat. * Fixed buggy SIGCHLD handling patch (their new pipe descriptors were leaked), removed unused pty_release and pty_make_controlling_tty functions which are not used, removed CRIT_LIBWRAP which needs to be inside CRIT_NTOA anyway. Thanks to Steve Grubb for these suggestions. * REMOTE_HOST variable is always placed in the environment of procesess spawned with 'exec'. * Added ENVIRONMENT section to man page, documenting REMOTE_HOST, SSL_CLIENT_DN and SSL_CLIENT_I_DN. * Removed entries from TODO, since development is in 4.x only. Version 3.24, 2002.04.23, urgency: HIGH: * Fixed bug whereby RSA blinding was called in client mode even when no cert was in use. * Patches no longer need to be public domain to be accepted into the Stunnel-3.x branch. Anything compatible with the existing GPL license is fine. Version 3.23, 2002.04.02, urgency: HIGH: * Enabled RSA blinding on all RSA keys to prevent RSA timing attack that was proven to be exploitable by David Brumley and Dan Boneh. See http://crypto.stanford.edu/~dabo/abstracts/ssl-timing.html for more details about the attack. If you have an OpenSSL library that has RSA blinding on by default (>=0.9.7b or >=0.9.6j) then you do not need to upgrade, but it is still suggested. * precompiled stunnel.exe no longer distributed in the source tarball * Brian Hatch <bri@stunnel.org> taking over maintenance of the Stunnel 3.x branch. New functionality should focus on the 4.x branch, 3.x will only be maintained for security and bugfixes.
7 lines
438 B
Text
7 lines
438 B
Text
The stunnel program is designed to work as SSL encryption wrapper between
|
|
remote client and local (inetd-startable) or remote server. The concept is
|
|
that having non-SSL aware daemons running on your system you can easily setup
|
|
them to communicate with clients over secure SSL channel.
|
|
|
|
stunnel can be used to add SSL functionality to commonly used inetd daemons
|
|
like POP-2, POP-3 and IMAP servers without any changes in the program code.
|