On 10/17/2016 2:04 PM, Paul Spangler wrote:
Hello,
Due to the way OpenSSL stores errors in a per-thread queue, functions
such as SSL_read followed by SSL_get_error may not produce the desired
result if the error queue is not empty prior to calling SSL_read[1]. For
example, a non-blocking read reports that no data is available by
setting up SSL_get_error to return SSL_ERROR_WANT_READ. But if an error
is already present in the queue, SSL_get_error sees that error instead
and returns SSL_ERROR_SSL.
I found at least one case where the error queue may be non-empty prior
to a non-blocking read[2] that involves combining mod_session_crypto
(which leaves the error queue non-empty) and the third-party
mod_websocket (which uses non-blocking reads), resulting in the
connection being closed. I included a potential patch to mod_ssl for
consideration on the bug report that simply clears the error queue prior
to any of the three SSL_* calls that mod_ssl makes. An ideal fix might
be to keep the error queue empty at all times (i.e. patch the APR crypto
library), but I propose that this patch is more robust in a modular
environment.
Thanks for your consideration.
[1]
https://www.openssl.org/docs/manmaster/ssl/SSL_get_error.html#DESCRIPTION
[2] https://bz.apache.org/bugzilla/show_bug.cgi?id=60223
Anyone have any thoughts on this small patch? It addresses an issue with
OpenSSL's per-thread state causing connections to fail.
Regards,
Paul Spangler
LabVIEW R&D
National Instruments
