Or to put it another way you can use combinations of... Use select() to check network level traffic arrival prior to making the appropriate SSL calls to handle it. Use SSL_Pending() to check if any SSL traffic is in the local buffers before calling select Set all sockets that you open to non-blocking mode prior to making any "slow" calls such as accept, connect, read, write, etc.
Typical architectures revolve around select and SSL_Pending, others on this list with more OpenSSL experience may like to chip in with better designs here... It is possible to handle multiple clients using a single thread, but it does get tricky as everything revolves around detecting activity and responding quickly before returning to detection mode again. Its impossible to do it reliably using blocking-mode calls. Regards, Simon Edwards -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of David Schwartz Sent: 20 July 2007 09:18 To: openssl-users@openssl.org Subject: RE: How to prevent SSL from blocking from Network interruption > Having only done minimal socket programming, I'm in a bit of a steep > learning curve right now. Other then understanding what a blocking and > non-blocking operation is, I don't fully understand the ramifications > of switching to non-blocking I/O. Compounding this issue is the third > party code, which was clearly written with blocking I/O :( You cannot write a program that serves multiple clients with a single thread and blocking socket operations. Blocking socket operations can block, and when you are blocked you cannot assist another client. If it does this with 'accept', for example, it will break. A TCP connection might be closed after you get a 'select' hit and before you enter 'accept'. In that case, the 'accept' will block until a new connection happens to come in. This can be remotely exploited. You have the same problem with 'write'. Suppose you get a 'select' hit that a socket is writable, but then you write more bytes that the system is willing to accept at that moment. Boom, you block, and you can't handle other clients. This is also remotely-exploitable -- just request a lot of stuff and don't call 'read'. Unfortunately, you will need to fix the broken code. On the bright side, OpenSSL has pointed out to you that the code is broken and now, with luck, you will not ship/deploy code that likely had numerous remotely exploitable denial-of-service vulnerabilities. DS ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager [EMAIL PROTECTED] This message has been scanned for viruses by MailController - www.MailController.altohiway.com ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
