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

[Thomas J. Hruska]

On 10/9/2017 7:49 AM, Jakob Bohm wrote:
> On 09/10/2017 16:43, Thomas J. Hruska wrote:
>> On 10/9/2017 7:29 AM, Jakob Bohm wrote:
>>> I suggest you find a good authoritative source for your claim
>>> that select() should not be used with blocking sockets.
>>
>> http://man7.org/linux/man-pages/man2/select.2.html
>>
>> Section BUGS:
>>
>> "Under Linux, select() may report a socket file descriptor as "ready 
>> for reading", while nevertheless a subsequent read blocks. This could 
>> for example happen when data has arrived but upon examination has 
>> wrong checksum and is discarded.  There may be other circumstances in 
>> which a file descriptor is spuriously reported as ready.  Thus it may 
>> be safer to use O_NONBLOCK on sockets that should not block."
>>
>>
>> Authoritative enough for you?
>>
> That must be a recent change then.  But certainly that is a bug
> in Linux select, not in programs relying on the (long time)
> documented correct behavior.

The OpenSSL layer over TCP/IP complicates matters more across ALL 
platforms:  SSL_read() may need to write (and SSL_write() may need to 
read).  Even if the socket has data to read according to select(), if 
the respective write end is full (or vice versa for SSL_write()), then 
the call WILL block when using blocking sockets.

You can't resolve the above issue with select() or any other function 
UNLESS you switch to non-blocking socket descriptors.  From that point, 
the only logical conclusion that can be drawn is that select() is for 
non-blocking I/O only.  Then the documented "bug" in Linux becomes a 
misunderstanding of what select() is actually intended for across all 
platforms:  Preventing spurious CPU usage for non-blocking I/O. 
select() is just a notification that MAYBE you can read or MAYBE you can 
write, but there is no guarantee of either succeeding.

-- 
Thomas Hruska
Shining Light Productions

Home of BMP2AVI and Win32 OpenSSL.
http://www.slproweb.com/