|
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]
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.
| 