Patch info for sslloop_pwagemans
Patch info for sslloop_pwagemans
Creator | Peter Wagemans |
---|
Patch to Version | 3.8pX |
---|
Type | new feature |
---|
Patch | sslloop_pwagemans.patch |
---|
Status | Integrated 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.
|