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."
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 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 List openssl-users@openssl.org
> Automated List Manager majordomo@openssl.org
>



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 majordomo@openssl.org