Re: SSL objects in fork() -> exec scenario
Hi Dave, Thank you for the response. Please find my reply inline - Original Message - From: <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Friday, September 29, 2006 4:43 PM Subject: FW: SSL objects in fork() -> exec scenario Hi Urjit: I think if the server parent executes and SSL_accept() and sends/recvs data with the client, your server-child process will not be able to work correctly. If you issue SSL_shutdown on the parent, it will notify the client that a shutdown is in progress. [Urjit]: Umm... Could you explain why? I mean, when the parent fork()'s the child has the exact image as that of the server. So even the SSL object and the SSL context object etc. will be copied as is in the child process space, correct? So why would the further communication from server-child will cause problem? I agree that if the server sends a SSL_shutdown() we would have issues. But then, what if the server, after knowing that the client has successfully been created, would just do a SSL_free to free its copy of the SSL object and go back to accepting more client connections? The server-child should still be able to use the SSL session, right? The other advice you got about deferring SSL_connect/SSL_accept sequence until AFTER the fork is the only option that I know of in this scenario. Since you don't have the freedom to start threads instead, it's pretty tricky. [Urjit]: Correct. This option would obviously work in a simple parent-child case. But the problem is more involved. My server parent would first establish a secured connection with the client. Then it would fork (but no exec here) and the child process would start communicating with the client. After this, at some point in time, the second process will detect a request from the client, which it will service by fork/exec ing yet another child. This is the point where I face problem. Now, When the server parent process forks a child, it has no idea if the child is further going to fork/exec a process. So even if I delay the SSL session creation and do it in first child, i would fall flat when this child fork/execs another process :-( This scheme worked fine with normal tcp/ip sockets, untill the need to secure the channel came up. Are you adding SSL support to an existing application? [Urjit]: Yes :-( If so, do you have to allow for a client who doesn't know how to negotiate the secure connection? If this is true, can you exchange the essential application handshake information in the clear, and start SSL work in the child? [Urjit]: Well ... that is possible. But two issues here. 1) I do not want the essential handshake information to be sent unencrypted, if both the client and server support SSL. 2) Even if I release this restriction, the second problem remains ... What when my child fork/exec a new process to serve the client request? In this case, we are facing the same issue again :-( I had this very challenge: I had to guarantee that older clients who didn't speak .. .(you might find my original questions and the answers about how to negotiate non-secure-upgrade-to-secure sessions). Good luck; I'd love to know how you solve it. [Urjit]: And I will love get this thing resolved, and share with all :-) Thank you for your response. ~ Urjit Dave McLellan -- Common Management Platform Engineering EMC Corporation 228 South St. Mail Stop: 228 2/C-19 Hopkinton, MA 01748 USA +1-508-249-1257 F: +1-508-497-8030 [EMAIL PROTECTED] -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Urjit Gokhale Sent: Friday, September 29, 2006 5:03 AM To: openssl-users@openssl.org Subject: Re: SSL objects in fork() -> exec scenario Hi Vlad and Dave, Thank you for your response. Unfortunately I do not have the freedom to change the existing implementation from fork/exec to threads (as suggested by Dave). Actually, the server reads certain input data from the client, and then based on the information it receives, it fork/exec the new process. Now, this information coming from the client has to be secured. So I secured the session between the Client and the Server right from the beginning (immediately after establishing a TCP connection). Also, the client does not care if fork/exec is taking place at the Server. It would continue to work based on the responses it would get from the server. In order to open a new session (SSL_connect() etc.) between the Client and the just fork/execed Child, the client would have to be aware of a connection request it would receive from the backend (Child). I do not want this. I am looking for a solution that will work exactly like classic TCP/IP session. The Client and Server establish a session. The Server fork/exec a new process. The Server lets go the session, and the Client and Child continue communication over this session. Is this possible with SSL ? Would the following solution work
Re: SSL objects in fork() -> exec scenario
Hi Vlad and Dave, Thank you for your response. Unfortunately I do not have the freedom to change the existing implementation from fork/exec to threads (as suggested by Dave). Actually, the server reads certain input data from the client, and then based on the information it receives, it fork/exec the new process. Now, this information coming from the client has to be secured. So I secured the session between the Client and the Server right from the beginning (immediately after establishing a TCP connection). Also, the client does not care if fork/exec is taking place at the Server. It would continue to work based on the responses it would get from the server. In order to open a new session (SSL_connect() etc.) between the Client and the just fork/execed Child, the client would have to be aware of a connection request it would receive from the backend (Child). I do not want this. I am looking for a solution that will work exactly like classic TCP/IP session. The Client and Server establish a session. The Server fork/exec a new process. The Server lets go the session, and the Client and Child continue communication over this session. Is this possible with SSL ? Would the following solution work? -- After the fork/exec the Child process will create its own SSL object with SSL_ctx_new() -> SSL_new(). It will then use the socket descriptor given by the Server and use it for SSL_set_fd(). So I am associating this new SSL object with the same socket. Then the new SSL object will initiate a renegotiation with the Client. After successful renegotiation, the Child and Client will start talking on this session. I am not sure what the Server should do in the mean time. Should it do a SSL_shutdown() or a simple SSL_free() or something different? Would the renegotiation triggered by the Child, on the same socket, with a completely new SSL object, work? Would a SSL_shutdown() or SSL_free() done by the server be safe? Would there be a race condition between the SSL_shutdown() / SSL_free() on Server and SSL renegotiation initiated by the Child? What could be the ramifications of such race condition? I am struggling to find answers to these questions ... Could someone help? Could someone share his experience? Could someone point to relevant information. Thank you for your help. ~ Urjit - Original Message - From: "Vlad W." <[EMAIL PROTECTED]> To: Sent: Thursday, September 28, 2006 4:47 PM Subject: Re: SSL objects in fork() -> exec scenario > The possible solution is to create own SSL instance in the child > process and to assign the socket returned by accept system call, i.e., > before SSL handshake. The parent server process should not handle SSL > for the current connection at all. > > E.g.: > /* > sock is the socket descriptor, > ctx is a pointer to SSL_CTX > */ > ... > SSL *ssl = SSL_new(ctx); > SSL_set_fd(sock); > ... > /* continue with SSL handshake */ > > Thanks, > Vlad > > On 9/28/06, Urjit Gokhale <[EMAIL PROTECTED]> wrote: > > > > Hi, > > > > Mentioned below is a normal tcp scenario. Could someone tell me how the > > following scenario be handled in SSL secured environment > > > > A. Client establishes a tcp connection with the Server > > B. Server Forks. > > C. Server exec's to start a new process. It passes its socket descriptor to > > the new process as command line argument. > > D. The new process uses the socket descriptor to communicate with the > > client. > > The idea here is to use the existing tcp connection for communication. > > > > Now, if we have this channel secured with SSL, the Client and Server both > > would have their SSL objects. They will communicate securely through these > > SSL object. The question here is, how can we provide the required SSL object > > to the new process, so that it would start using the pre established secured > > session / channel? > > > > One possible solution I could think of is to use shared memory between the > > Server and new process. The server, before it exec the new process would > > create a copy of its SSL object in the shared memory and the new process > > then will use it. > > > > But I am not sure if such copying of SSL object is safe. > > Is there any other solution possible? > > Could someone guide me through this? > > > > Thank you, > > ~ UrjitDISCLAIMER == 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
Re: SSL objects in fork() -> exec scenario
The possible solution is to create own SSL instance in the child process and to assign the socket returned by accept system call, i.e., before SSL handshake. The parent server process should not handle SSL for the current connection at all. E.g.: /* sock is the socket descriptor, ctx is a pointer to SSL_CTX */ ... SSL *ssl = SSL_new(ctx); SSL_set_fd(sock); ... /* continue with SSL handshake */ Thanks, Vlad On 9/28/06, Urjit Gokhale <[EMAIL PROTECTED]> wrote: Hi, Mentioned below is a normal tcp scenario. Could someone tell me how the following scenario be handled in SSL secured environment A. Client establishes a tcp connection with the Server B. Server Forks. C. Server exec's to start a new process. It passes its socket descriptor to the new process as command line argument. D. The new process uses the socket descriptor to communicate with the client. The idea here is to use the existing tcp connection for communication. Now, if we have this channel secured with SSL, the Client and Server both would have their SSL objects. They will communicate securely through these SSL object. The question here is, how can we provide the required SSL object to the new process, so that it would start using the pre established secured session / channel? One possible solution I could think of is to use shared memory between the Server and new process. The server, before it exec the new process would create a copy of its SSL object in the shared memory and the new process then will use it. But I am not sure if such copying of SSL object is safe. Is there any other solution possible? Could someone guide me through this? Thank you, ~ UrjitDISCLAIMER == 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 objects in fork() -> exec scenario
In our server application we removed all fork()/exec() from our server once we started using openSSL. At that time, we were using fork/exec on some platforms, pthreads on others. We swapped the forking platforms over to use pthreads were very reliable results. I believe we saw this symptom: following SSL connect/accept, the client sends its first message, which is recv'd by the parent before it actually closes its copy of the socket. The child, the process which should be send/recv'ing with the client never sees what it expects. There's more to it than that, but I can't remember more details. If you have the freedom to use pthreads instead of fork/exec, I'd recommend it. Dave McLellan -- Common Management Platform Engineering EMC Corporation 228 South St. Mail Stop: 228 2/C-19 Hopkinton, MA 01748 USA +1-508-249-1257 F: +1-508-497-8030 [EMAIL PROTECTED] From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Urjit GokhaleSent: Thursday, September 28, 2006 5:11 AMTo: openssl-users@openssl.orgSubject: SSL objects in fork() -> exec scenario Hi, Mentioned below is a normal tcp scenario. Could someone tell me how the following scenario be handled in SSL secured environment A. Client establishes a tcp connection with the Server B. Server Forks. C. Server exec's to start a new process. It passes its socket descriptor to the new process as command line argument. D. The new process uses the socket descriptor to communicate with the client. The idea here is to use the existing tcp connection for communication. Now, if we have this channel secured with SSL, the Client and Server both would have their SSL objects. They will communicate securely through these SSL object. The question here is, how can we provide the required SSL object to the new process, so that it would start using the pre established secured session / channel? One possible solution I could think of is to use shared memory between the Server and new process. The server, before it exec the new process would create a copy of its SSL object in the shared memory and the new process then will use it. But I am not sure if such copying of SSL object is safe. Is there any other solution possible? Could someone guide me through this? Thank you, ~ UrjitDISCLAIMER == 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.
