This is a discussion on Re: SSL objects in fork() -> exec scenario - Openssl ; 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 ...
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.
sock is the socket descriptor,
ctx is a pointer to SSL_CTX
SSL *ssl = SSL_new(ctx);
/* continue with SSL handshake */
On 9/28/06, Urjit Gokhale
> 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
> 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 email@example.com
Automated List Manager firstname.lastname@example.org