Re: SSL_connect and SSL_accept deadlock!
This may be a stretch, but did you confirm the socket is within the range of sockets your platform allows you to 'select' on? For example, Linux by default doesn't permit you to 'select' on socket numbers 1,025 and up, though you can have more than 1,024 file descriptors in use without a problem. DS __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: SSL_connect and SSL_accept deadlock!
On 11/2/2010 6:25 PM, Md Lazreg wrote:
r=select(m_sock_fd + 1, fds, 0, 0, ptv);
if (r = 0 (Errno == EAGAIN || Errno == EINTR))/*if we timed
out with EAGAIN try again*/
{
r = 1;
}
This code is broken. If 'select' returns zero, checking errno is a
mistake. (What is 'Errno' anyway?)
r = SSL_connect(m_ssl);
if (r 0)
{
break;
}
r = ssl_retry(r);
if ( r = 0)
{
break;
}
t = time(NULL) - time0;
}
Err, what? Is an ssl_retry return of zero supposed to indicate a fatal
error? The code in ssl_retry doesn't seem to follow this rule. (For
example, consider if 'select' returns zero and errno is zero. That would
indicate a timeout, not a fatal error.)
int time0 = time(NULL);
timeout=10 seconds;
while (ttimeout)
{
r = SSL_accept(m_ssl);
if (r 0)
{
break;
}
r = ssl_retry(r);
if ( r = 0)
{
break;
}
t = time(NULL) - time0;
}
if (t=timeout)
There no code to initially set 't'.
Also, an overall comment: Maybe it's just my taste, but your code seems
to have a 'worst of both worlds' quality to it. It uses non-blocking
sockets, but then finds clever ways to make the non-blocking operations
act like blocking ones.
Is the server multithreaded? If so, I could see this as mere laziness
(or, efficient use of coding resources to be more charitable) rather
than actual poor design.
DS
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager majord...@openssl.org
Re: SSL_connect and SSL_accept deadlock!
On Wed, Nov 3, 2010 at 9:12 AM, David Schwartz dav...@webmaster.com wrote:
On 11/2/2010 6:25 PM, Md Lazreg wrote:
r=select(m_sock_fd + 1, fds, 0, 0, ptv);
if (r = 0 (Errno == EAGAIN || Errno == EINTR))/*if we timed
out with EAGAIN try again*/
{
r = 1;
}
This code is broken. If 'select' returns zero, checking errno is a mistake.
(What is 'Errno' anyway?)
[SNIP]
Is the server multithreaded? If so, I could see this as mere laziness (or,
efficient use of coding resources to be more charitable) rather than actual
poor design.
lol
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager majord...@openssl.org
SSL_connect and SSL_accept deadlock!
I have an SSL client that connects to an SSL server. The server is able to
process 1000s of clients just fine on a variety of platforms
[Window/Linux/HP/Solairs] for long periods of time.
The problem that is driving me nuts is that from time to time like once
every 24 hours some client fails to connect to the server at the handshaking
phase. This happens only on Linux and HP. Other platforms do not experience
this issue.
Here is a sketch of my client and server code. Please note that I am using non
blocking sockets:
common code:
-
int ssl_retry(int ret)
{
int r;
fd_set fds;
struct timeval tv, *ptv=0;
tv.tv_sec = 1;/*do a select for 1 second each time*/
tv.tv_usec = 0;
ptv=tv;
FD_ZERO(fds);
switch(SSL_get_error(m_ssl, ret)
{
case SSL_ERROR_NONE:
r = 1;
break;
case SSL_ERROR_WANT_READ:
FD_SET(m_sock_fd, fds);
r=select(m_sock_fd + 1, fds, 0, 0, ptv);
if (r = 0 (Errno == EAGAIN || Errno == EINTR))/*if we timed out
with EAGAIN try again*/
{
r = 1;
}
break;
case SSL_ERROR_WANT_WRITE:/
FD_SET(m_sock_fd, fds);
r=select(m_sock_fd + 1, 0, fds, 0, ptv);
if (r = 0 (Errno == EAGAIN || Errno == EINTR))/*if we timed out
with EAGAIN try again*/
{
r = 1;
}
break;
case SSL_ERROR_ZERO_RETURN:/*The socket closed*/
r = 0;
break;
case SSL_ERROR_SYSCALL:
case SSL_ERROR_SSL:
r = -1;
break;
default:
r = -1;
}
return r;
client code:
-
int time0 = time(NULL);
timeout=10 seconds;
while (ttimeout)
{
r = SSL_connect(m_ssl);
if (r 0)
{
break;
}
r = ssl_retry(r);
if ( r = 0)
{
break;
}
t = time(NULL) - time0;
}
if (t=timeout)
{
I timed out:(
}
if (r0)
{
We are connected. Do work.
}
else
{
Some kind of an issue.
}
server code:
-
int time0 = time(NULL);
timeout=10 seconds;
while (ttimeout)
{
r = SSL_accept(m_ssl);
if (r 0)
{
break;
}
r = ssl_retry(r);
if ( r = 0)
{
break;
}
t = time(NULL) - time0;
}
if (t=timeout)
{
I timed out:(
}
if (r0)
{
We are connected. Do work.
}
else
{
Some kind of an issue.
}
When this problem happens both the client and the server end up in the red
line above I timed out
With some debugging efforts I see that when this problem hits, both the
client and the server go repeatedly into the green section above, each one
of them seems to want to perform a read as the returned code
is SSL_ERROR_WANT_READ from both the SSL_connect and the SSL_accept calls.
This looks to me as a deadlock situation where both my server and my client
are wanting to do a READ until both of them timeout!
Can someone please suggest to me what is wrong with the above code and how
is this deadlock possible?? I am using openssl-1.0.0a
SSL_connect, and SSL_accept
Where are SSL_accept, and SSL_connect defined? Specifically for TLSv1, and SSLv3 connections. I found the definition in ssl_lib.c but then that calls s-method-ssl_accept(s). From here the only mention I could find of an ssl3_accept is in s3_srvr.c which to my understanding is not part of the library, and is part of an example program. Any suggestions are appreciated. Thank you, -Sam -- Sam Jantz Software Engineer
RE: SSL_connect, and SSL_accept
From: owner-openssl-us...@openssl.org On Behalf Of Sam Jantz
Sent: Tuesday, 07 September, 2010 17:29
Where are SSL_accept, and SSL_connect defined? Specifically
for TLSv1, and SSLv3 connections. I found the definition
in ssl_lib.c but then that calls s-method-ssl_accept(s).
Right; the common API SSL_{accept,connect,read,etc} dispatches
to protocol-specific routines determined (only?) by the 'method'
you used to create your SSL*, and those often dispatch further.
Mostly these are ssl2_* for SSL2, ssl3_* for SSL3, ssl23_* for
composite, tls1_* for TLS1, dtls1_* for DTLS1, but I think
I've seen some exceptions here and there.
From here the only mention I could find of an ssl3_accept
is in s3_srvr.c which to my understanding is not part of
the library, and is part of an example program.
Everything in SOURCE/ssl is part of libssl except ssltest.
The pure examples are in SOURCE/demos, and the commandline
utilities which can also be examples are in SOURCE/apps.
(And nearly all of SOURCE/crypto/* -- 2 levels -- is libcrypto.)
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager majord...@openssl.org
RE: SSL_connect and SSL_accept
Original message Date: Fri, 30 Mar 2007 12:01:54 -0700 From: David Schwartz [EMAIL PROTECTED] Subject: RE: SSL_connect and SSL_accept To: openssl-users@openssl.org So what you are saying is the scenario we have been discussing so far is possible ONLY in case of memory allocation issues NOT OTHERWISE. I guess I will have a look at the SSL_connect code before I just trust this :-) I would still recommend coding to handle this case. Perhaps the next version of OpenSSL will include a check in SSL_connect that this version does not have. It's not a good idea to build undocumented insider information about a library into code that calls into that library. You should do that only when there is a very good reason. DS Thank you David, I guess I understand what you are suggesting. Better not rely on the current implementation of any function provided by the library, as it may change any time. It is better to write a code that relys only on the documented facts and does not assuming anything not mentioed there. ~ Urjit 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 Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: SSL_connect and SSL_accept
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 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) 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
Re: SSL_connect and SSL_accept
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
Re: SSL_connect and SSL_accept
snip 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. /snip So what you are saying is the scenario we have been discussing so far is possible ONLY in case of memory allocation issues NOT OTHERWISE. I guess I will have a look at the SSL_connect code before I just trust this :-) 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? The response from the server is guarenteed unless the underlying tcp channel is in trouble. If SSL_connect fails, the client will block in tcp recv(). If SSL_connect succeeds, the client will block in SSL_read() The client is guarenteed to return, either when it gets The client either gets a response from the server or gets a tcp error and then decides what to do next. The session layer should be concerned about this, as long as it does not get any tcp errors. 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. Agreed. You cannot fix the symptom, u need to fix the cause and that is why this HYPOTHETICAL error occured in the 1st place. First thing is that I am more worried about my server blocking in a SSL_accept() forever. I might be able to get rid of this with timeout. Secondly, I want the communication to continue even if SSL session establishment fails. Now it is obvious that I can not do much in case the error due to which SSL_connect returnd failure is unrecoverable (memory issue is one of them). But if the error is recoverable (which as per your openion an IMPOSSIBLE thing) I would like to attempt further communication on plain tcp socket, for which I want my server to be ready to accept next tcp data packet. I guess I will have a look at the SSL code to see if there are possibilities, other than memory allocation issues, when SSL_connect returns error, unless of course someone who knows the code makes any authoritive statement here :-) Thank you very much for your help. ~ Urjit 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 Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
RE: SSL_connect and SSL_accept
So what you are saying is the scenario we have been discussing so far is possible ONLY in case of memory allocation issues NOT OTHERWISE. I guess I will have a look at the SSL_connect code before I just trust this :-) I would still recommend coding to handle this case. Perhaps the next version of OpenSSL will include a check in SSL_connect that this version does not have. It's not a good idea to build undocumented insider information about a library into code that calls into that library. You should do that only when there is a very good reason. DS __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
RE: SSL_connect and SSL_accept
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 Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
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 Listopenssl-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 Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
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 Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED
Re: SSL_connect and SSL_accept
Urjit Gokhale wrote: I believe you are confusing tcp/ip connection establishment and SSL session establishment. ... and you should also remember that a reliable transport is a prerequisite for tls. 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. i believe your problem maybe the case when a TCP session is in place but an SSL session is not started (client problems or a malicious client trying to DoS you). A timeout maybe what you are looking for. You could rely on tcp's timeout (if no data is sent TCP_KEEPALIVE isn't selected, it should timeout) or have your own application timer to keep server resource's from being wasted by a incomplete sessions. -jb __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: SSL_connect and SSL_accept
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
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
Re: SSL_connect and SSL_accept
I am wondering if the following scenario possible: 1) The server calls SSL_accept(). The underlying socket is in blocking mode 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(). Am not sure what you mean from the 4th point, server does not notice this. TCP is a connection oriented protocol and if the connect fails on the client, then the server will get a valid error message, but that depends on where the failure has happened. If the failure is at the TCP level say if the client fails to even open a socket (client application) then the server is not even bothered as its listening on port 443 and wont even receive any SYN packets. When SSL_Accept is made blocking, it only means that the call to SSL_accept will not return until the SSL handshake is completed and during that point of time, the application will not be able to accept any new tcp requests, provided its all handled as part of the same thread. If ur going to fork and then block, then u dont have any problem (if you dont want to go for non blocking mode). If the SSL handshake fails the appropriate error message will be seen by the server and it will definitely not MISS it..and if there is a tcp level failure after the tcp connection is established .. say u get a RST..then SSL_accept will break and return the error to the calling application. 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. Thanks --Gayathri If the scenario mentioned above is possible, then the server will be blocked in the SSL_accept() (until the underlying tcp connection is broken) and hence wont be able to service other clients' connection requests This is the Toyota Principle, you asked for it, you got it. If you don't want to block, don't use blocking sockets. The only mechanism that can assure that a socket operation will not block is non-blocking sockets. Thanks for responding. I will definitely consider using non blocking sockets here. But what I am more interested in knowing is 'whether' the scenario that I mentioned is possible, and has anyone ever experienced it. ~ Urjit 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 Listopenssl-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 Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
SSL_connect and SSL_accept
Hello, I am wondering if the following scenario possible: 1) The server calls SSL_accept(). The underlying socket is in blocking mode 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(). This question might have an obvious answer, but I would still like to hear your views/opinions/facts. If the scenario mentioned above is possible, then the server will be blocked in the SSL_accept() (until the underlying tcp connection is broken) and hence wont be able to service other clients' connection requests Any comments? 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.
RE: SSL_connect and SSL_accept
If the scenario mentioned above is possible, then the server will be blocked in the SSL_accept() (until the underlying tcp connection is broken) and hence wont be able to service other clients' connection requests This is the Toyota Principle, you asked for it, you got it. If you don't want to block, don't use blocking sockets. The only mechanism that can assure that a socket operation will not block is non-blocking sockets. DS __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: SSL_connect and SSL_accept
If the scenario mentioned above is possible, then the server will be blocked in the SSL_accept() (until the underlying tcp connection is broken) and hence wont be able to service other clients' connection requests This is the Toyota Principle, you asked for it, you got it. If you don't want to block, don't use blocking sockets. The only mechanism that can assure that a socket operation will not block is non-blocking sockets. Thanks for responding. I will definitely consider using non blocking sockets here. But what I am more interested in knowing is 'whether' the scenario that I mentioned is possible, and has anyone ever experienced it. ~ Urjit 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 Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
problems with SSL_connect and SSL_accept
I am adding OpenSSL 0.9.7e to an existing Windows XP application and I am new to OpenSSL. This application is both a TCP server and a TCP client. Since I'm adding OpenSSL support to both the client side and the server side, I thought I could test the OpenSSL changes by having the application connect to itself. I created a Certificate Authority and the certificates described in Network Security with OpenSSL, Viega et al, chapter 5. I then used these certificates in the application. However, OpenSSL has problems with these certificates in both SSL_connect() and SSL_accept(). Here are the error messages from SSL_connect(): Error with certificate at depth 0: error 18: self signed certificate. Certificate issuer: /CN=exampleCA/ST=Washington/C=US/[EMAIL PROTECTED]/O=Root Certification Authority. Certificate subject: /CN=exampleCA/ST=Washington/C=US/[EMAIL PROTECTED]/O=Root Certification Authority. error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed: . SSL error location: file '.\ssl\s3_clnt.c' line 844. Here are the error messages from SSL_accept(): error:14094418:SSL routines:SSL3_READ_BYTES:tlsv1 alert unknown ca: SSL alert number 48. SSL error location: file '.\ssl\s3_pkt.c' line 1052. Can anyone tell me why this doesn't work? My guess is that this has something to do with a self signed certificate, but I'm ignorant of the implications of this. I appreciate any help you can give. __ John Hoel Product Author Skywire Software 2401 Internet Blvd., Suite 201 Frisco, Texas 75034 (972)377-1110 main (425)396-4687 direct [EMAIL PROTECTED] www.skywiresoftware.com NO RELIANCE: This e-mail will be of no force of effect and will not be binding unless a hard copy of this e-mail, signed by an authorized official of the company, has been sent to the recipient of this message. CONFIDENTIAL AND/OR PROPRIETARY: Information contained in this transmission is intended for the use of the individual or entity named above and may contain legally proprietary or confidential information. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copy of this communication is strictly prohibited. If you have received this communication in error, please permanently delete this message and immediately notify us by telephone at 972-377-1110. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Fork() after a good SSL_connect and SSL_accept - does it work?
Title: Fork() after a good SSL_connect and SSL_accept - does it work?
I have a closed ('closed' in the sense that produce the client and the server applications) client/server application which optionally uses SSL to secure the session. It's a mature propretiary client/server protocol which has been enhanced to add the SSL support.
On most platforms, the server starts a new thread to handle a new connection, but this happens after we execute the connect/accept sequence. That is, the listener thread accepts and SSL_accepts the client, and then starts a new thread to handle the client.
On a couple of platforms, we can't, because of unrelated architectural reasons, use a thread for a new session. We have to fork a new process after the accepting the client. Is there any prayer for the child process, with inherited socket and memory image of the SSL structures, to actually succeed? Do I need to re-initialize the library and everything else in the child process? What the heck else would I have to do in this architecture.
Does anyone have experience with SSL in forked environments? Thanks for your advice. I have seen some hits on fork behavior in the archives but no answers.
Dave McLellan --Consulting Software Engineer - SPEA Engineering
EMC Corporation
228 South St. Mail Stop: 228 LL/AA-24
Hopkinton, MA 01748 USA
+1-508-249-1257 F: +1-508-497-8030 [EMAIL PROTECTED]
Re: Fork() after a good SSL_connect and SSL_accept - does it work?
I've got a client/server pair in which the server forks for each
connection. It calls fork() after the accept() returns and then
does all the ssl gymnastics in the child process. Other than probably
being a bit more costly than using a thread, it works fine.
Paul Allen
mclellan, dave wrote:
I have a closed ('closed' in the sense that produce the client and the
server applications) client/server application which optionally uses SSL
to secure the session. It's a mature propretiary client/server
protocol which has been enhanced to add the SSL support.
On most platforms, the server starts a new thread to handle a new
connection, but this happens after we execute the connect/accept
sequence. That is, the listener thread accepts and SSL_accepts the
client, and then starts a new thread to handle the client.
On a couple of platforms, we can't, because of unrelated architectural
reasons, use a thread for a new session. We have to fork a new process
after the accepting the client. Is there any prayer for the child
process, with inherited socket and memory image of the SSL structures,
to actually succeed? Do I need to re-initialize the library and
everything else in the child process? What the heck else would I have
to do in this architecture.
Does anyone have experience with SSL in forked environments? Thanks for
your advice. I have seen some hits on fork behavior in the archives but
no answers.
--
Boeing Phantom Works \ Paul L. Allen, (425) 865-3297
Math Computing Technology \ [EMAIL PROTECTED]
POB 3707 M/S 7L-40, Seattle, WA 98124-2207 \ Prototype Systems Group
__
OpenSSL Project http://www.openssl.org
User Support Mailing List[EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
SSL_connect and SSL_accept
Hi again,
My problem with SSL_connect and SSL_accept that I
was having yesterday has been tracked down to this...
ssl23_get_server_hello
ssl23_read_bytes...
and then ...
int ret=0;
if (out != NULL){#ifndef
BIO_FDclear_socket_error();ret=readsocket(b-num,out,outl);
I've made a few changes to my code, such as
explicitly setting the method, ensuring that SSL_set_connect_state() has been
called (For the client) and SSL_set_accept_state() has been called for the
server. I moved away from using a BIO_
for associating the socket with SSL, and rather
tried the SSL_set_fd() call - now it blocks at that readsocket(). (Almost what I
was expecting - but why is nothing coming back ?)
Anybody who can help, it would be greatly
appreciated.
__
PascalQbik New Zealand
"meddle not in the affairs of dragons, for ye
are crunchy and taste good with tomato
sauce"
