Hmm... I am surprised to see how I have managed to confuse you. I thought my previous post was pretty clear. Anyway, I will try to explain again.
The client and server have and existing tcp connection, which is healthy. There is no problem with the tcp connection throughout the scenario. The client, for some reason decides to have a secured session, and so with its own protocol, tells the server to allow a secured session. After seeing such request from client (This is still a tcp communication, SSL is still not in picture), the server creates a SSL object, calls SSL_set_fd(sock_serv) and then calls SSL_accept The Client creates its SSL object, calls SSL_set_fd(sock_cli) and calls SSL_connect() Now *before* SSL_connect can actually write something on the tcp channel, using tcp send() or write(), something goes wrong and it returns an error to its caller. So there is nothing placed on the tcp channel. The server is waiting for the SSL handshake packet which it never get because SSL_connect() could never send it. Hope the scenario I am talking about is clear now. The reason why I am interested in knowing if something like what is written above can happen is: I want my client and server to be able to communicate with/without SSL If the SSL session establishment fails, the client/server can decide to kill the underlying tcp channel, or can decide to go ahead unsecured. In the scenario mentioned above, the client knows that SSL session establishment has failed, because SSL_connect() returned an error. So it may, as per its configuration decide to go ahead with unsecured communication. On he other side of the tcp link, the server is still waiting for SSL handshake packet, which the client was expected to send, which the client never sent due to some error. So here is the problem. I want my server to detect that something went wrong with the client and it should fall back to the unsecured communication. The issue here is HOW can my server detect the SSL_connect() failure that occurred on the client side? Anything that the client would send after SSL_connect() failure, will in fact be taken up by SSL_accept() and SSL_accept() will now error out saying it read invalid SSL handshake packet. Now as I write down this whole thing, I wonder if even non-blocking sockets can help. Does it look more like a design issue ? ~ Urjit ----- Original Message ----- From: "Gayathri Sundar" <[EMAIL PROTECTED]> To: <openssl-users@openssl.org> Sent: Thursday, March 29, 2007 4:07 PM Subject: Re: SSL_connect and SSL_accept 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] 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]
