Thanks for replying. I guess we are on the same page now. The only thing is that you are asking the same question that I am asking everyone on this list .... "What scenario may cause the SSL_connect to return error to the caller, without writing a single byte on the underlying tcp connection (which is healthy) ?" Can someone think of such a scenario? Has anyone ever experienced this before?
I have spent quite some time with SSL_connect, and apart from tcp level socket failures (transient/fatal) and SSL Handshake failures it cannot return error, so ur case is NOT POSSIBLE unless the HOST has run out of memory wherein Openssl_malloc itself fails. So I dont suppose you need to worry about that. I guess you have already mentioned one such scenario ... memory allocation issues, which could cause SSL_connect to return before it could write something on the socket. Are there other such possibilities? SSL_init failures is not a candidate here, as I am already doing what you have suggested "dont attempt SSL at all if SSL_init fails". What I am considering is *some* error, that occurs *just as I enter SSL_connect*. Looking at the SSL_connect code may provide an answer, and I will surely consider this option. But I was looking for a response from folks who already know this code, and have better idea of what SSL_connect does before it writes its first byte on the socket. May be they can say if they foresee a case when SSL_connect can error out without writing a byte on the socket. As far as the synchronization between the server and the client goes, may be I can consider reading a feed back from the server. So the execution sequence will be like Client calls SSL_connect() Client waits for servers response (No matter if SSL_connect fails or succeeds) >> Tell me if the client fails, why and how long will you wait for feedback? Also isnt that TCP's job? Why should the session layer worry about this? >>If the client failes with a malloc and memory corruption issues, you might >>as well restart your application..there is no point waiting on any >>feedback. >>You cannot fix the symptom, u need to fix the cause and that is why this >>HYPOTHETICAL error occured in the 1st place. The server has a non blocking socket it calls SSL_accept() if succeeds, it would report success to the client if failure (timeout), it would report failure to the client ~ Urjit ----- Original Message ----- From: "Gayathri Sundar" <[EMAIL PROTECTED]> To: <openssl-users@openssl.org> Sent: Friday, March 30, 2007 9:25 AM Subject: Re: SSL_connect and SSL_accept I am quite clear with your problem and am not confused. The only point I have been stressing from beginning is that SSL_connect due to WHATEVER error it returns a failure to the calling application, the peer WILL know for the simple fact that a "socket send " cannot fail unless the FD itself is not created/the host is not in the network/ or the interface is down or simply if the HOST runs out of MEMORY, I am not able to think of an error case wherein the SSL_connect fails to send a message out when the underlying TCP connection is ALIVE and KICKING. WHY? WHAT SORT OF ERROR ARE YOU ANTICIPATING that SSL_connect will return FAILURE to its application without even sending 1 byte on the wire? UNLESS SSL_INIT itself fails on the client or SSL OBJECT creation fails? If that is the FAILURE ur worried about then you might as well initiate a TCP teardown from the client and not attempt SSL anymore.. I hope I am able to explain better..see only in severe application programming errors/memory leak or whatever the SSL init itself will fail..so if the SSL init fails on the client side DONT initiate SSL at all so that the server will not go into SSL_accept. Why will SSL OBJ creation fail? CAN you explain to me WHAT ERROR UR TALKING ABOUT that SSL_CONNECT will return FAILURE TO CALLING APPLICATION without sending 1BYTE on the wire when the TCP CONNECTION IS A-OK? I can think of "BUGGY CODING"..and I dont think Non blocking will solve ur problem as its never going to detect this FAILURE THAT UR TALKING ABOUT..unless you implement POLL TIMEOUT i.e the FD will never SELECT as it never receives any DATA, so ur POLL TIMER should cleanup that FD if say it doesnt select within 5mins or so.. This is my solution: 1. Make ur FDs non blocking 2. Start a timer per FD basis before ur add it into ur POLL table 3. Everytime the FD selects on a POLLIN/POLLOUT restart ur timer 4. On TimerExpiration clean up that FD coz it never received any DATA for the timeout period, due to n/w or client failures. Decide on a good timeout value.. Thanks --Gayathri 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]
