David,
Agreed. If any object in shared memory contained a pointer to
another
object in shared memory this could cause a problem. You would have
to
ensure that the shared memory was mapped to the same address in all
processes otherwise the pointers would not be valid.
Since he's
Since he's talking about a process that forks, there
shouldn't be a problem.
He just needs to create a shared mapping in the parent. After
the 'fork', the address will still be the same.
However if the program forks and calls exec* then this issue could
arise. The title of the thread
The point of SSL is to provide (possibly) data integrity (detection of
tampering and validation of the source of the data) and secrecy
services /on the wire/. The endpoints have always been known to be
points of concern as they must maintain the keys, both private and
symmetric, in their memory
Of course, it will be great to have a feature in OpenSSL
implementation iteslf that will enable SSL session handover / or
even session sharing between multiple related processes.
Session sharing is pretty hard to do. Handover is not quite as hard. I think
that would be a really great feature.
Hi,
For the multithreaded version of OpenSSL, there's a pre-initialization
function that you must call to tell it what memory allocation function
to use. Writing a function like this to only return memory allocated
from shared memory for use by OpenSSL wouldn't be difficult, but it
Agreed. If any object in shared memory contained a pointer to another
object in shared memory this could cause a problem. You would have to
ensure that the shared memory was mapped to the same address in all
processes otherwise the pointers would not be valid.
Cheers,
Mark
Since he's
, 2006 11:06 AM
To: openssl-users@openssl.org
Subject: RE: How to share SSL session when using CreateProcess/execv
Agreed. If any object in shared memory contained a pointer
to another
object in shared memory this could cause a problem. You
would have to
ensure that the shared
Why are you forking a child that you want to directly access the SSL
stream, then? Why not have the child write into shared memory, and
have the parent send it out itself?
Well ... an option of creating a thread in the parent that would work as
a proxy for the child, taking care of all the
Hello,
Why are you forking a child that you want to directly access the SSL
stream, then? Why not have the child write into shared memory, and
have the parent send it out itself?
Well ... an option of creating a thread in the parent that would work as
a proxy for the child, taking care
I think that all SSL read/write operation may be performed in parent.
Child may communicate with socket/pipe/popen or other IPC mechanism.
For example assume that server parent has established SSL connection
with client parent and waits for commands from client.
Client sends information to
Hello,
I was just trying to weigh the option of doing things with shared memory. I
believe mod_ssl does this ... possibly they share ssl sessions through
shared memory, but I dont have the details.
After looking at mod_ssl source it looks that SSL_SESSION objects
are being kept in shared
On 10/11/06, Urjit Gokhale [EMAIL PROTECTED] wrote:
Well ... this is exactly what I wanted to do, but so far I havent found a
way to
achieve this. As far as my knowledge goes, SSL_new() internally calls
CRYPTO_malloc, which in turn makes call to malloc(). Now malloc()
would just allocate a block
Hi,
Hello,
For the moment, i have a kind of supervisor which,
accept a connection, read some datas on the socket and
then start the process which is able to handle this
datas. ( using createprocess/execv). The socket's
handle is shared to this process and therefor the
process is able
The receiver state and the sender state are different. So, in theory,
this could work... though it'd be difficult with the way that OpenSSL
handles renegotiation.
I wouldn't recommend it, though. The way I'd do it is hand off the
SSL session entirely to the child. (Then, the parent could
Thank you for the quick reply.
Please find my comments inline
- Original Message -
From: Kyle Hamilton [EMAIL PROTECTED]
To: openssl-users@openssl.org
Sent: Tuesday, October 10, 2006 11:48 PM
Subject: Re: How to share SSL session when using CreateProcess/execv
The receiver state
My comments also inline
On 10/10/06, Urjit Gokhale [EMAIL PROTECTED] wrote:
I wouldn't recommend it, though. The way I'd do it is hand off the
SSL session entirely to the child. (Then, the parent could close the
socket, and since the client still has it it would stay open.)
So, the
Hello,
I really hope that there is a way to do it. And i
would be very happy if someone can help me.
You can not share ssl3/tls1 session by using SSL
object in two different processes.
For example one process establish ssl session then
fork()'s and two processes use SSL object for
It's not yet finished, but i've done some tests and
they are sucessfull...
Thank you for this hint.
--- Richard Salz [EMAIL PROTECTED] a écrit :
There is no pre-existing way to write out all the
SSL state so that
another process can reconstruct it.
I would do it this way; when a
Hello,
parent accept() and SSL_accept() then fork(), parent
SSL_free() and close() and child to some work.
What work would that be? It should not be possible for the child
process to splice itself into the middle of an SSL session without
the required cryptographic state...
Of course,
Hello,
For the moment, i have a kind of supervisor which,
accept a connection, read some datas on the socket and
then start the process which is able to handle this
datas. ( using createprocess/execv). The socket's
handle is shared to this process and therefor the
process is able to exchange
Marek Marcola wrote:
[EMAIL PROTECTED] writes:
For the moment, i have a kind of supervisor which,
accept a connection, read some datas on the socket and
then start the process which is able to handle this
datas. ( using createprocess/execv). The socket's
handle is shared to this process and
First i want to thank you both for your quick answers.
It's quite hard to change the design as its an old
application which must be upgraded to SSL.
Maybe what i've said was not clear enough.
In fact, i don't want two processes to be able to
communicate on the socket at the same time.
I just
There is no pre-existing way to write out all the SSL state so that
another process can reconstruct it.
I would do it this way; when a connection comes in, spawn stunnel to
handle the SSL with a pipe() back to the dispatcher. Use raw read on the
pipe; when it's time to spawn a client, hand
On Fri, Jul 21, 2006 at 03:55:09PM +0200, Frederic Renault wrote:
First i want to thank you both for your quick answers.
It's quite hard to change the design as its an old
application which must be upgraded to SSL.
Maybe what i've said was not clear enough.
In fact, i don't want two
Hello,
Maybe what i've said was not clear enough.
In fact, i don't want two processes to be able to
communicate on the socket at the same time.
I just would like the process which has accepted the
connection to give the SSL object to a second process.
Then the first process doesn't need
On Sat, Jul 22, 2006 at 12:46:35AM +0200, Marek Marcola wrote:
parent accept() and SSL_accept() then fork(), parent
SSL_free() and close() and child to some work.
What work would that be? It should not be possible for the child
process to splice itself into the middle of an SSL session without
26 matches
Mail list logo
