Stunnel.org  
   
Home
About
News
Faq
Examples
Download
Patches
Support
Related
<Patch List> <Patch Directory>
Patch info for sslloop_pwagemans

Patch info for sslloop_pwagemans

CreatorPeter Wagemans
Patch to Version3.8pX
Typenew feature
Patchsslloop_pwagemans.patch
StatusIntegrated into stunnel-3.9.
Description

(Full Text)

Improved SSL loop code, based on the state_machine.c from Ben Laurie.

According to users who have tried it, this fixes the annoying random stalls and hangs that stunnel has occasionaly experienced on certain platforms or with other SSL software.

Author Comments


I've been away from the stunnel stall problem for a couple of days,
but here is another attempt at fixing the stunnel transfer loop, after
a look at Ben Laurie's recent example code in state_machine.c. I have
attempted to preserve the different structure of stunnel and
incorporate the IO logic of the example.

Since I am not familiar with the innards of OpenSSL and since I
haven't found descriptions of the relevant OpenSSL functions, this is
unfortunately based on assumptions derived from the names of functions
and some peeks at the code. I was aiming to minimise the work needed
to fix stunnel, so I may well have formulated unwarranted assumptions
;-) I'll try to summarise the most important ones, and hope that some
expert can find some time to have a look. Please point out mistakes
since the proposed fix depends on them. Actual code for the new
stunnel transfer routine is below. (I've chosen to quote it
completely, not just the differences, to facilitate analysis. My
apologies if it is considered inappropriate to quote about 200 lines
of code.)

Note: stunnel uses SSL_set_fd to supply a socket to the SSL library
for reading and writing on the SSL connection.

Major assumptions:

	SSL_want_read and SSL_want_write can be used to see if a previous
	operation was not completed and what kind of IO on the underlying
	file descriptor is needed to continue.

	The SSL library does NOT require an identical retry as the next
	SSL IO operation. If an SSL_read was not completed, one can also
	retry with a larger count, or even do an SSL_write first, then
	retry SSL_read again.  If an SSL_write was not completed, one can
	also retry with a larger count, or even do an SSL_read first, then
	retry SSL_write again.

	SSL_pending can be used to see if the SSL library has buffered
	application data available, already read and decrypted from the
	underlying socket.

With these assumptions the proposed stunnel SSL IO behaviour is as
follows, in each iteration of the select loop:

    The SSL file descriptor is selected for read if

          stunnel has buffer space to read
      or  stunnel has data to write to SSL and SSL_want_read is true

    The SSL file descriptor is selected for write if

          stunnel has data to write to SSL
      or  stunnel has buffer space to read and SSL_want_write is true

    After the select, SSL_read and SSL_write are done as follows:

        attempt SSL_write if stunnel has data to write (maybe
            increased from previous amount) and

         either  SSL file descriptor ready for write
           or    SSL_want_read and SSL file descriptor ready for read

        attempt SSL_read if stunnel has buffer space to read and:

         either  SSL file descriptor ready for read
           or    just made room in read buffer and SSL_pending
           or    SSL_want_write and SSL file descriptor ready for write


By the way, the code runs my applications (on Solaris 2.5.1 and NT 4)
just as well as the previous fix. It only attempts to take the
possibilities of SSL_want_* into account. I guess it isn't easy to
create conditions where the new code is actually relevant.

Regards,

Peter Wagemans






This website makes patches available for use by the Internet community. However it does not endorse any of the patches contained herein. They could be work perfectly, or totally foul up everything. We don't know. Contact the authors if you have any questions. Use at your own risk.

The Stunnel software package does not contain any cryptography itself, however please remember that import and/or export of cryptographic software, code providing hooks to cryptographic algorithms, and discussion about cryptography is illegal in some countries. It is imperative for you to know your local laws governing cryptography. We're not liable for anything you do that violates your local laws.