[PATCH] make neon with OpenSSL truly timeout on read
Diego Santa Cruz
Diego.SantaCruz at spinetix.com
Tue May 21 05:24:29 EDT 2013
The way neon uses OpenSSL for https connections makes it possible for an
https connection to block indefinitely on read despite setting a read
The problem stems from the fact that SSL/TLS is record oriented, so having
some data in the raw socket does not necessarily mean that OpenSSL may return
data from the SSL/TLS socket.
Currently (0.29.6) neon calls readable_ossl() to know if data is available on
the socket. This in turn calls SSL_pending() to know if there is data
available on the SSL/TLS socket and if not it calls readable_raw() to know if
there is available data on the raw socket. Hence, as soon as there are a few
bytes in the raw socket readable_ossl() will return success, but if there is
in fact less than the SSL record size available trouble will occur when
SSL_read() is called later, as that function will block until a whole SSL
record may be read from the raw socket, which may never happen.
In our application we encounter this issue with unstable 3G networks.
Sometimes the underlying connection breaks down and only a partial SSL record
has been received, then SSL_read() block indefinitely as explained above (as
the connection is broken the remaining part of the SSL record never arrives).
The attached patch solves this for OpenSSL by setting the raw socket to
non-blocking. It has been deployed in our application with success on Win32
and Linux (x86 and ARM).
As am I not versed in GnuTLS I do not know if neon's use of GnuTLS is also
affected by this problem or not and the patch only covers OpenSSL.
Diego Santa Cruz, PhD
Rue des Terreaux 17
1003, Lausanne, Switzerland
T +41 21 341 15 50
F +41 21 311 19 56
diego.santacruz at spinetix.com
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 10807 bytes
Url : http://lists.manyfish.co.uk/pipermail/neon/attachments/20130521/755c956a/attachment.obj
More information about the neon