> 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 featur
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 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 th
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'
nt: Thursday, October 12, 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 pro
> 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 h
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
> wou
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 bloc
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 memo
> 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 t
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, tak
> 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,
> > > 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
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
Thank you for the quick reply.
Please find my comments inline
- Original Message -
From: "Kyle Hamilton" <[EMAIL PROTECTED]>
To:
Sent: Tuesday, October 10, 2006 11:48 PM
Subject: Re: How to share SSL session when using CreateProcess/execv
> The receiver state and t
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 close
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
> > proc
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 cour
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 withou
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 n
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 tw
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 the
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 wou
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 ther
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 exc
26 matches
Mail list logo
