[openssl-users] Graceful shutdown of TLS connection for blocking sockets

[Kyle Hamilton]

Important caveat: SSL_read() and SSL_write() don't directly return
SSL_ERROR_WANT_READ or SSL_ERROR_WANT_WRITE. Those values are returned
by SSL_get_error().

I apologize for the misstatement.

-Kyle H


On Sun, Oct 8, 2017 at 5:58 PM, Kyle Hamilton <aerowolf at gmail.com> wrote:
> Do you have a reference to what should be done instead?
>
> My understanding of what happens with blocking sockets is that
> SSL_read() will return SSL_ERROR_WANT_READ if it needs additional data
> read from a socket that doesn't have it available (and will return
> SSL_ERROR_WANT_WRITE if it needs to write for a handful of reasons,
> but can't).  I had thought that the appropriate response would be to
> add that descriptor to the appropriate set to query on the next call
> to select(), and then call the same function with the same parameters
> so the library can advance its state machine.
>
> write() and read() have the means to tell you how much data was
> written or read, and that's what you're supposed to use to keep
> blocking descriptors from hanging your application, I thought.
>
> -Kyle H
>
>
> On Sun, Oct 8, 2017 at 6:48 AM, Thomas J. Hruska
> <shinelight at shininglightpro.com> wrote:
>> On 10/8/2017 4:17 AM, Kyle Hamilton wrote:
>>>
>>> The way to handle this situation is simply to never enter SSL_read() if
>>> there isn't anything to read on the socket.  select() or pselect() are
>>> your
>>> friends, here, because they'll tell you if there's data to read from the
>>> underlying file descriptor.
>>>
>>> I hope this helps!
>>>
>>> -Kyle H
>>
>>
>> Since the OP is talking about blocking sockets, I'm going to reiterate
>> something someone pointed out to me on this very list many years ago and
>> save someone a LOT of headaches:
>>
>> select() should NEVER, EVER be used for blocking sockets.
>>
>>
>> Just because select() returns any given descriptor doesn't mean that a call
>> won't still block when working with blocking sockets.  select() is for
>> non-blocking descriptors ONLY.  The amount of extra code involved for
>> handling non-blocking sockets is actually quite minimal when a state engine
>> is adopted.
>>
>> I'd love to see select() implementations raise an exception and kill the
>> whole application off when passing it a blocking descriptor.  Then we would
>> discover how much broken software is floating around out there. Since I
>> still see lots of recommendations for using select() with blocking
>> descriptors and all of the official system-level documentation for select()
>> is silent on this issue, I'm guessing a lot.
>>
>> --
>> Thomas Hruska
>> Shining Light Productions
>>
>> Home of BMP2AVI and Win32 OpenSSL.
>> http://www.slproweb.com/
>>
>> --
>> openssl-users mailing list
>> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users