Urjit., 1st of all theoritically your are 100% correct, after all SSL runs in the SESSION layer, but it depends on the underlying transport connection, and if that has problems, SSL has problems. Now Am not sure why you expect the TCP connection to be A-OK and still get an SSL_connect failure. If the failure is with the HANDSHAKE, like mismatch in version/cipher suite or something the SSL ALERT RECORD will take care and eventually close the connection.
The only case is what David says, if the peer has been disconnected coz of some power/network failure, then the client will succeed in SENDING the Handshake message but never receive any ACK, so the TCP will endup doing retransmissions. SSL_connect WILL NOT return with ERRORS in this case. Its all blocked, I agree, but YOUR scenerio of SSL_CONNECT failing and SSL_ACCEPT not knowing that CANNOT happen. SSL_connect will SUCCEED and BLOCK indifinitely, waiting for a PEER ACK, and the server will not even be alive. If the server was ALIVE, why would it not respond. Go for Non Blocking sockets, if that suits your requirement, but your scenerio cannot happen in blocking mode, infact if your scenerio does happen, then even in non blocking mode it will end up looping, only difference is between successive POLLs ur application has control, there will be a loop between ur SELECT and SSL_CONNECT, latter always retruning some TRANSIENT retry errors. Probably u could have a count and cleanup.. I dont see how Non Block will solve ur problem, IF it can occur. Thanks --Gayathri I believe you are confusing tcp/ip connection establishment and SSL session establishment. As far as my understanding goes: SSL is an application level protocol, that works on an existing tcp channel. So, SSL handshake can be thought of as two network applications talking to each other. It is obvious that, the moment first SSL handshake packet reaches the server, the server would change its state and will now start with the handshake. If anything goes wrong hereafter (Invalid packet, tcp error, lost packet ... ), the server's SSL_accept will detect that and report error. The problem may occur when: 1) Server is waiting for first SSL handshake packet in SSL_accept 2) Client attempts to establish SSL handshake with SSL_connect 3) SSL_connect fails even before it could send the first SSL handshake packet. So the client has put nothing on the network. Now, SSL_connect has returned an error in the client, and the server is still blocked in SSL_accept. Gayathri, You are correct about first forking and then attempting SSL_accept. This will save the main server from blocking into SSL_accept and failing to server other client connection requests. Here the forked child will be blocked in SSL_accept though. David, As I have already acknowledged in my previous post, the option of using non blocking socket seems to be the way to go. I have a few doubts on how a particular scenario can be handled, but I feel it is a bit off track with respect to the current thread. So I will send a new post for that. Thank you everyone for responding. ~ Urjit ----- Original Message ----- From: "Gayathri Sundar" <[EMAIL PROTECTED]> To: <openssl-users@openssl.org> Sent: Thursday, March 29, 2007 1:02 PM Subject: RE: SSL_connect and SSL_accept Yes, I agree with you, but then why would the CLIENT get an ERROR? >2) The client calls SSL_connect(). The underlying socket is in blocking >mode >3) SSL_connect() returns error. >4) The server does not notice this, and continues to wait in SSL_accept(). if SSL_connect indeed has returned with ERROR..then the SSL_accept should also return with an ERROR, unless the data transmission was LOST!!! In ur case the CLIENT will go on retrying sending the same message with the TCP retransmitting the pkt as no ACK was received on the client side..and if I am correct..it tries 3 times on linux and returns with an error..so it does not block FOREVER..there is no concept of blocking FOREVER..literally.. yes but then NON BLOCKING sockets are ofcourse the best solution esp when ur appliance is designed for the enterprise markets. Thanks --Gayathri > I am unable to think of a scenerio why ur case is possible unless some > serious network congestion has developed and pkts were lost..i dont > see how..but the experts might able to give u a better idea. You get a SYN, send a SYN ACK, other side sends an ACK, then the other side's Internet connection goes down due to an extended power failure. You will be waiting for it to send the first SSL handshake message forever. Blocking function block until the operation completes, fails, or it is proven impossible for it to ever succeed. DS ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager [EMAIL PROTECTED] **************************************************************************** **** This email message (including any attachments) is for the sole use of the intended recipient(s) and may contain confidential, proprietary and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please immediately notify the sender by reply email and destroy all copies of the original message. Thank you. Intoto Inc. ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager [EMAIL PROTECTED] DISCLAIMER ========== This e-mail may contain privileged and confidential information which is the property of Persistent Systems Pvt. Ltd. It is intended only for the use of the individual or entity to which it is addressed. If you are not the intended recipient, you are not authorized to read, retain, copy, print, distribute or use this message. If you have received this communication in error, please notify the sender and delete all copies of this message. Persistent Systems Pvt. Ltd. does not accept any liability for virus infected mails. ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager [EMAIL PROTECTED] ******************************************************************************** This email message (including any attachments) is for the sole use of the intended recipient(s) and may contain confidential, proprietary and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please immediately notify the sender by reply email and destroy all copies of the original message. Thank you. Intoto Inc. ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
