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,
~ 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.
|
- SSL objects in fork() -> exec scenario Urjit Gokhale
- RE: SSL objects in fork() -> exec scenario mclellan_dave
- Re: SSL objects in fork() -> exec scenario Vlad W.
- Re: SSL objects in fork() -> exec scenario Urjit Gokhale
- Re: SSL objects in fork() -> exec scenario Urjit Gokhale
- Transfer Encoding : Chunked Vinu Thomas
- RE: Transfer Encoding : Chunked David Schwartz
- RE: Transfer Encoding : Chunked André Ziermann