Graceful shutdown of TLS connection for blocking sockets

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
19 messages Options
Reply | Threaded
Open this post in threaded view
|

Graceful shutdown of TLS connection for blocking sockets

mahesh gs
Hi All,

I have query regarding the SSL_read on blocking socket. How to come out of blocking SSL_read when we have to close the connection ?

As per the documentation SSL_read will only return if there is any data or an error occurred.

 "If the underlying BIO is blocking, SSL_read() will only return, once the read operation has been finished or an error occurred, except when a renegotiation take place, in which case a SSL_ERROR_WANT_READ may occur"

I am trying following methods 

method 1:

1) Thread - 1 blocks in SSL_read
2) Thread - 2 receive indication to stop the connection from application. Call SSL_Shutdown() to unblock the SSL_read in thread - 1. But this is dangerous as calling SSL_shutdown and SSL_read from different threads on same context can lead to undefined behaviour.

method 2:

1) Thread - 1 blocks in SSL_read
2) Thread - 2 receive indication to stop the connection from application. shutdown the underlying TCP socket using system command (shutdown (socket_id, SHUT_WR)) that cause the SSL_read to unblock.
3) Thread - 1 unwind and close the TCP socket (using close(socket_id)). thread -1 cannot call SSL_Shutdown since the TCP socket is shutdown by thread - 2 for write operation. As per my understanding this violates the TLS standard because of not sending out the close notify handshake.

How to ensure to come out of blocking SSL_read and initiate SSL_shutdown from same thread?

Thanks,
Mahesh G S

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Graceful shutdown of TLS connection for blocking sockets

Kyle Hamilton
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

On Oct 5, 2017 02:58, "mahesh gs" <[hidden email]> wrote:
Hi All,

I have query regarding the SSL_read on blocking socket. How to come out of blocking SSL_read when we have to close the connection ?

As per the documentation SSL_read will only return if there is any data or an error occurred.

 "If the underlying BIO is blocking, SSL_read() will only return, once the read operation has been finished or an error occurred, except when a renegotiation take place, in which case a SSL_ERROR_WANT_READ may occur"

I am trying following methods 

method 1:

1) Thread - 1 blocks in SSL_read
2) Thread - 2 receive indication to stop the connection from application. Call SSL_Shutdown() to unblock the SSL_read in thread - 1. But this is dangerous as calling SSL_shutdown and SSL_read from different threads on same context can lead to undefined behaviour.

method 2:

1) Thread - 1 blocks in SSL_read
2) Thread - 2 receive indication to stop the connection from application. shutdown the underlying TCP socket using system command (shutdown (socket_id, SHUT_WR)) that cause the SSL_read to unblock.
3) Thread - 1 unwind and close the TCP socket (using close(socket_id)). thread -1 cannot call SSL_Shutdown since the TCP socket is shutdown by thread - 2 for write operation. As per my understanding this violates the TLS standard because of not sending out the close notify handshake.

How to ensure to come out of blocking SSL_read and initiate SSL_shutdown from same thread?

Thanks,
Mahesh G S

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users


--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Graceful shutdown of TLS connection for blocking sockets

Thomas J. Hruska
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
Reply | Threaded
Open this post in threaded view
|

Re: Graceful shutdown of TLS connection for blocking sockets

Michel
While I understand that using non-blocking descriptors is a better practice,
I still do not see why select() should NEVER be used for blocking sockets
(except when combined/interfered with the internal OpenSSL state machine or
equivalent mechanism).

Could you please elaborate or give an example ?
 
Regards,

Michel.

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Graceful shutdown of TLS connection for blocking sockets

Thomas J. Hruska
On 10/8/2017 7:28 AM, Michel wrote:

> While I understand that using non-blocking descriptors is a better practice,
> I still do not see why select() should NEVER be used for blocking sockets
> (except when combined/interfered with the internal OpenSSL state machine or
> equivalent mechanism).
>
> Could you please elaborate or give an example ?
>  
> Regards,
>
> Michel.

Example:  You call select(), it returns the descriptor as readable, you
pass it into SSL_read(), and SSL_read() blocks.  You are worse off than
before you used select() since you made the incorrect assumption that
you could do something when select() returns and not have a blocking
socket block.

Just because select() says that something is readable (or writable) does
not actually make it so.  The function only makes sense for non-blocking
descriptors.  The use of select() with a blocking descriptor is always
wrong.

Non-blocking code is actually easier to implement than you think.

--
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
Reply | Threaded
Open this post in threaded view
|

Re: Graceful shutdown of TLS connection for blocking sockets

Michel
Hi Thomas,

I do not think that non-blocking code is hard to implement, but I am not
still convinced there is not some kind of confusion here.
Pardon me if I do not understand well your reasoning, but I just want to
highlight that SSL_read() contract is not to return TCP data, but SSL/TLS
data (if some are available), which is more work.
As described in https://www.openssl.org/docs/man1.1.0/ssl/SSL_read.html, you
may encounter cases where TCP data is available, but just contains TLS
records with no usefull application data.

Can this be what you experienced or I missed your point ?

Regards,

Michel
 

-----Message d'origine-----
De : openssl-users [mailto:[hidden email]] De la part de
Thomas J. Hruska
Envoyé : dimanche 8 octobre 2017 22:56
À : [hidden email]
Objet : Re: [openssl-users] Graceful shutdown of TLS connection for blocking
sockets

On 10/8/2017 7:28 AM, Michel wrote:

> While I understand that using non-blocking descriptors is a better
> practice, I still do not see why select() should NEVER be used for
> blocking sockets (except when combined/interfered with the internal
> OpenSSL state machine or equivalent mechanism).
>
> Could you please elaborate or give an example ?
>  
> Regards,
>
> Michel.

Example:  You call select(), it returns the descriptor as readable, you pass
it into SSL_read(), and SSL_read() blocks.  You are worse off than before
you used select() since you made the incorrect assumption that you could do
something when select() returns and not have a blocking socket block.

Just because select() says that something is readable (or writable) does not
actually make it so.  The function only makes sense for non-blocking
descriptors.  The use of select() with a blocking descriptor is always
wrong.

Non-blocking code is actually easier to implement than you think.

--
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

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Graceful shutdown of TLS connection for blocking sockets

Karl Denninger
In reply to this post by mahesh gs

In short ssl is not the same as a raw socket fd because of the intervening protocol.

That's all....

  Original Message  
From: [hidden email]
Sent: October 8, 2017 4:34 PM
To: [hidden email]
Reply-to: [hidden email]
Subject: Re: [openssl-users] Graceful shutdown of TLS connection for blocking sockets

Hi Thomas,

I do not think that non-blocking code is hard to implement, but I am not
still convinced there is not some kind of confusion here.
Pardon me if I do not understand well your reasoning, but I just want to
highlight that SSL_read() contract is not to return TCP data, but SSL/TLS
data (if some are available), which is more work.
As described in https://www.openssl.org/docs/man1.1.0/ssl/SSL_read.html, you
may encounter cases where TCP data is available, but just contains TLS
records with no usefull application data.

Can this be what you experienced or I missed your point ?

Regards,

Michel


-----Message d'origine-----
De : openssl-users [mailto:[hidden email]] De la part de
Thomas J. Hruska
Envoyé : dimanche 8 octobre 2017 22:56
À : [hidden email]
Objet : Re: [openssl-users] Graceful shutdown of TLS connection for blocking
sockets

On 10/8/2017 7:28 AM, Michel wrote:

> While I understand that using non-blocking descriptors is a better
> practice, I still do not see why select() should NEVER be used for
> blocking sockets (except when combined/interfered with the internal
> OpenSSL state machine or equivalent mechanism).
>
> Could you please elaborate or give an example ?
>  
> Regards,
>
> Michel.
Example:  You call select(), it returns the descriptor as readable, you pass
it into SSL_read(), and SSL_read() blocks.  You are worse off than before
you used select() since you made the incorrect assumption that you could do
something when select() returns and not have a blocking socket block.

Just because select() says that something is readable (or writable) does not
actually make it so.  The function only makes sense for non-blocking
descriptors.  The use of select() with a blocking descriptor is always
wrong.

Non-blocking code is actually easier to implement than you think.

--
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

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

smime.p7s (6K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Graceful shutdown of TLS connection for blocking sockets

Kyle Hamilton
In reply to this post by Thomas J. Hruska
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
<[hidden email]> 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
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: 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 <[hidden email]> 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
> <[hidden email]> 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
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Graceful shutdown of TLS connection for blocking sockets

Thomas J. Hruska
In reply to this post by Kyle Hamilton
On 10/8/2017 5:58 PM, Kyle Hamilton 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

With blocking sockets, you just loop back around and repeat the same
call if either of those messages are returned by SSL_get_error().  No
select() required.

Blocking operations will block (aka "hang") your application until the
operation completes.  If you don't want that to happen, then that's what
non-blocking descriptors are for.

--
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
Reply | Threaded
Open this post in threaded view
|

Re: Graceful shutdown of TLS connection for blocking sockets

Michel
> With blocking sockets, you just loop back around and repeat the same call
if either of those messages are returned by SSL_get_error(). No select()
required.

Yes, you have to repeat the same call, but select() is still usefull,
especially with blocking sockets.

Regards,

Michel.

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Graceful shutdown of TLS connection for blocking sockets

Thomas J. Hruska
On 10/9/2017 1:32 AM, Michel wrote:
>> With blocking sockets, you just loop back around and repeat the same call
> if either of those messages are returned by SSL_get_error(). No select()
> required.
>
> Yes, you have to repeat the same call, but select() is still usefull,
> especially with blocking sockets.

And leads to incorrect code and weird blocking scenarios.  Been there,
done that.  You're using select() wrong.  If you want to block, then
block and don't try to hack around it.  Otherwise use non-blocking.

This common misunderstanding of select() is precisely why calling it
with a blocking descriptor should trigger an exception that kills the
application.  Doing so would bring a quick end to a lot of bad code.

--
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
Reply | Threaded
Open this post in threaded view
|

Re: Graceful shutdown of TLS connection for blocking sockets

Jakob Bohm-7
On 09/10/2017 15:31, Thomas J. Hruska wrote:

> On 10/9/2017 1:32 AM, Michel wrote:
>>> With blocking sockets, you just loop back around and repeat the same
>>> call
>> if either of those messages are returned by SSL_get_error(). No select()
>> required.
>>
>> Yes, you have to repeat the same call, but select() is still usefull,
>> especially with blocking sockets.
>
> And leads to incorrect code and weird blocking scenarios.  Been there,
> done that.  You're using select() wrong.  If you want to block, then
> block and don't try to hack around it.  Otherwise use non-blocking.
>
> This common misunderstanding of select() is precisely why calling it
> with a blocking descriptor should trigger an exception that kills the
> application.  Doing so would bring a quick end to a lot of bad code.
>
The system documentation (at least on Linux) isn't just silent
about how select behaves with blocking sockets.  It is
*explicitly* written to describe how it works with blocking
sockets (but is mostly silent about non-blocking sockets).
(My copy is marked as being from Linux man-pages project version
3.74).

I suggest you find a good authoritative source for your claim
that select() should not be used with blocking sockets.

Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Graceful shutdown of TLS connection for blocking sockets

Thomas J. Hruska
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?

--
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
Reply | Threaded
Open this post in threaded view
|

Re: Graceful shutdown of TLS connection for blocking sockets

Jakob Bohm-7
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.

Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Graceful shutdown of TLS connection for blocking sockets

Michel
In reply to this post by Thomas J. Hruska
Hi Thomas,

As mentioned previously, I do NOT "want to block" or "hack" with OpenSSL
state machine.
And again, I agree with you that non-blocking socket programming is best and
more flexible.

I just wanted to understand your point and it is now clear for me since I
read the BUGS section of http://man7.org/linux/man-pages/man2/select.2.html.
Thanks for this, I was not aware of that, I learned something today.
:-)

However I don't think this is a "common misunderstanding of select()" as it
is a *BUG* [hopefully] of only select() under linux.
Not a design implementation of *select() and friends* (pselect, poll, epoll,
...) on every other systems.
And on this matter, I don't believe that code relying on interface
documentation is *bad code* by nature, and - IMHO - a bug should be fixed
rather than killing everything around (kind of terrorism programming ? ;-).

Anyway, thanks to have shared your opinion and advices with me.

Regards,

Michel.


-----Message d'origine-----
De : openssl-users [mailto:[hidden email]] De la part de
Thomas J. Hruska
Envoyé : lundi 9 octobre 2017 15:32
À : [hidden email]
Objet : Re: [openssl-users] Graceful shutdown of TLS connection for blocking
sockets

On 10/9/2017 1:32 AM, Michel wrote:
>> With blocking sockets, you just loop back around and repeat the same
>> call
> if either of those messages are returned by SSL_get_error(). No
> select() required.
>
> Yes, you have to repeat the same call, but select() is still usefull,
> especially with blocking sockets.

And leads to incorrect code and weird blocking scenarios.  Been there, done
that.  You're using select() wrong.  If you want to block, then block and
don't try to hack around it.  Otherwise use non-blocking.

This common misunderstanding of select() is precisely why calling it with a
blocking descriptor should trigger an exception that kills the application.
Doing so would bring a quick end to a lot of bad code.

--
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

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Graceful shutdown of TLS connection for blocking sockets

Thomas J. Hruska
In reply to this post by Jakob Bohm-7
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/
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Graceful shutdown of TLS connection for blocking sockets

Michel
[...]
> From that point, the only logical conclusion that can be drawn is that select() is for non-blocking I/O only.
[...]

Ouahhh, it looks to me as an over-simplistic conclusion !
select() was not designed and written with future TLS state machine implementation in mind.

But maybe I shoudn't relaunch a debate...

:-)

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Graceful shutdown of TLS connection for blocking sockets

Verhelst Wouter (Consultant)
In reply to this post by Thomas J. Hruska


On 08-10-17 22:55, Thomas J. Hruska wrote:

> On 10/8/2017 7:28 AM, Michel wrote:
>> While I understand that using non-blocking descriptors is a better
>> practice,
>> I still do not see why select() should NEVER be used for blocking sockets
>> (except when combined/interfered with the internal OpenSSL state
>> machine or
>> equivalent mechanism).
>>
>> Could you please elaborate or give an example ?
>>   Regards,
>>
>> Michel.
>
> Example:  You call select(), it returns the descriptor as readable, you
> pass it into SSL_read(), and SSL_read() blocks.  You are worse off than
> before you used select() since you made the incorrect assumption that
> you could do something when select() returns and not have a blocking
> socket block.
>
> Just because select() says that something is readable (or writable) does
> not actually make it so.

Er, yes it does. Perhaps not as much as you wanted, but yes there will
be something there.

> The function only makes sense for non-blocking
> descriptors.  The use of select() with a blocking descriptor is always
> wrong.

Er, no it isn't.

Example: you select() on all your file descriptors in your main thread.
When select() tells you that one of them is ready to read, you fire off
a message to a thread pool and have one of the worker threads in that
thread pool (eventually) handle reading your data in a blocking manner.
Once the thread from the thread pool has finished reading, it will start
work on another file descriptor. This allows you to serve more clients
than you have threads, so allows to avoid overloading your server, but
since you use blocking I/O on your file descriptors you can get away
with not having the extra complexity of the state machine that blocking
I/O requires.

You can't implement that properly without doing select() on blocking
file descriptors, however.

> Non-blocking code is actually easier to implement than you think.

It isn't too hard, to write, that's true. It's more difficult to reason
about and to avoid bugs with, however (and for thread pools, you just
use a library -- e.g., GThreadPool from libglib).

--
Wouter Verhelst
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users