This is a multi-part message in MIME format.

------_=_NextPart_001_01C6E2E7.14155D56
Content-Type: text/plain;
charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

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.=20
=20
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.=20
=20
If you have the freedom to use pthreads instead of fork/exec, I'd
recommend it.=20

Dave McLellan -- Common Management Platform Engineering=20
EMC Corporation=20
228 South St. Mail Stop: 228 2/C-19=20
Hopkinton, MA 01748 USA=20
+1-508-249-1257 F: +1-508-497-8030 mclellan_dave@emc.com=20

=20


________________________________

From: owner-openssl-users@openssl.org
[mailtowner-openssl-users@openssl.org] On Behalf Of Urjit Gokhale
Sent: Thursday, September 28, 2006 5:11 AM
To: openssl-users@openssl.org
Subject: SSL objects in fork() -> exec scenario
=09
=09
Hi,
=20
Mentioned below is a normal tcp scenario. Could someone tell me
how the following scenario be handled in SSL secured environment
=20
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.=20
=20
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?
=20
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.
=20
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?
=20
Thank you,
~ Urjit
DISCLAIMER =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 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.=20


------_=_NextPart_001_01C6E2E7.14155D56
Content-Type: text/html;
charset="us-ascii"
Content-Transfer-Encoding: quoted-printable



charset=3Dus-ascii">




face=3DArial=20
color=3D#0000ff size=3D2>In our server application we removed all =
fork()/exec() from=20
our server once we started using openSSL. At that time, we were =
using=20
fork/exec on some platforms, pthreads on others.  We swapped the =
forking=20
platforms over to use pthreads were very reliable results. =

face=3DArial=20
color=3D#0000ff size=3D2>
 

face=3DArial=20
color=3D#0000ff size=3D2>I believe we saw this symptom: following SSL=20
connect/accept, the client sends its first message, which is recv'd by =
the=20
parent before it actually closes its copy of the socket.   The =
child,=20
the process which should be send/recv'ing with the client never sees =
what it=20
expects.  There's more to it than that, but I can't remember more =
details.=20

face=3DArial=20
color=3D#0000ff size=3D2>
 

face=3DArial=20
color=3D#0000ff size=3D2>If you have the freedom to use pthreads instead =
of=20
fork/exec, I'd recommend it.

Dave McLellan -- =
Common Management=20
Platform Engineering

face=3DArial=20
size=3D2>EMC Corporation

face=3DArial=20
size=3D2>228 South St. Mail Stop: 228 2/C-19

lang=3Den-us>Hopkinton, MA 01748  =
USA
=20

+1-508-249-1257 F:=20
+1-508-497-8030  mclellan_dave@emc.com


 






From: =
owner-openssl-users@openssl.org=20
[mailtowner-openssl-users@openssl.org] On Behalf Of Urjit=20
Gokhale
Sent: Thursday, September 28, 2006 5:11 =
AM
To:=20
openssl-users@openssl.org
Subject: SSL objects in fork() =
-> exec=20
scenario



Hi,

 

Mentioned below is a normal tcp =
scenario. Could=20
someone tell me how the following scenario be handled in SSL secured=20
environment

 

A. Client establishes a tcp =
connection with the=20
Server

B. Server Forks.

C. Server exec's to start a new =
process. It=20
passes its socket descriptor to the new process as command line=20
argument.

D. The new process uses the socket =
descriptor=20
to communicate with the client.

The idea here is to use the =
existing tcp=20
connection for communication
. =

 

Now, if we have this channel =
secured with SSL,=20
the Client and Server both would have their SSL objects. They will =
communicate=20
securely through these SSL object.
size=3D2>The=20
question here is, how can we provide the required SSL object to =
the new=20
process, so that it would start using the pre established secured =
session /=20
channel?

 

One possible solution I could think =
of is to=20
use shared memory between the Server and new process. The server, =
before it=20
exec the new process would create a copy of its SSL object in the =
shared=20
memory and the new process then will use it.

 

But I am not sure if such copying =
of SSL object=20
is safe.

Is there any other solution=20
possible?

Could someone guide me through=20
this?

 

Thank you,

~ Urjit
DISCLAIMER =
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D This=20
e-mail may contain privileged and confidential information which is =
the=20
property of Persistent Systems Pvt. Ltd. It is intended only for the =
use of=20
the individual or entity to which it is addressed. If you are not the =
intended=20
recipient, you are not authorized to read, retain, copy, print, =
distribute or=20
use this message. If you have received this communication in error, =
please=20
notify the sender and delete all copies of this message. Persistent =
Systems=20
Pvt. Ltd. does not accept any liability for virus infected mails.=20


------_=_NextPart_001_01C6E2E7.14155D56--
__________________________________________________ ____________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager majordomo@openssl.org