Re: [openssl-users] Graceful shutdown of TLS connection for blocking sockets
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
[...] > 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
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
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
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
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
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
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
> 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
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
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
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
In short ssl is not the same as a raw socket fd because of the intervening protocol. That's all Original Message From: michel.sa...@free.fr Sent: October 8, 2017 4:34 PM To: openssl-users@openssl.org Reply-to: openssl-users@openssl.org 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: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 smime.p7s Description: S/MIME cryptographic signature -- 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
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
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
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
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
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
[openssl-users] Graceful shutdown of TLS connection for blocking sockets
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