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

[Wouter Verhelst]

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

Re: [openssl-users] 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

Re: [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/
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

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

[Michel]

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:openssl-users-boun...@openssl.org] De la part de
Thomas J. Hruska
Envoyé : lundi 9 octobre 2017 15:32
À : openssl-users@openssl.org
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

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

[Jakob Bohm]

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

Re: [openssl-users] 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

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

[Jakob Bohm]

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

Re: [openssl-users] 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

Re: [openssl-users] 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

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

[Thomas J. Hruska]

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

Re: [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  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
>  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

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

[Kyle Hamilton]

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

Re: [openssl-users] 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:openssl-users-boun...@openssl.org] De la part de
Thomas J. Hruska
Envoyé : dimanche 8 octobre 2017 22:56
À : openssl-users@openssl.org
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

Re: [openssl-users] 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

Re: [openssl-users] 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

Re: [openssl-users] 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

Re: [openssl-users] 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"  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