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 server parent cant close the socket etc. as it has things to do once
the server child is done.
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?
> I remember one design that we had to retrofit SSL into where the
> parent process forked, sharing the open handles with the child, which
> then wrote out to all of them when the child's work was finished.
> Needless to say, this dropped all the connections that used SSL when
> it happened.
>
Sorry, but I am not quite sure I follow what you are saying.
Basically, what happened was this:
When the child was forked, it inherited the handles, as well as the
then-current state of all of the SSL objects. The child took some
time to complete, and during that time there was communication between
the parent and the client. When the child completed, it tried to
write using its own idea of the SSL states (the ones that hadn't had
the HMAC and sequence numbers updated), thus causing a fatal alert to
be sent by the client.
A standard TCP session being written to by multiple processes is no
problem, since the TCP is managed by the kernel and writes by multiple
processes all go through the single interface. SSL/TLS, though, is
MUCH more stringent, especially as it's implemented in user space.
> Another possibility is if you have the SSL object in shared memory,
> surrounded by a mutex. I advise against this as it's extremely
> difficult to debug in these situations.
Thank you for warning me about this, as I had never thought of debugging
issues. But neverthless, I would like to konw how an SSL object could be put
in the
shared memory and be accessed by two processes (the parent child scenario
described above).
I can think of two approaches to put a SSL object in shared memory.
1. One is to have ssl library create the ssl object (SSL_new()) in a shared
memory region.
I think you should be able to do this (note, however, that I take no
responsibility if this blows up in your face, as I've never had a
design like this). Allocate the memory within the shared region and
then SSL_new() on that memory. (Remember that ALL access to shared
memory must be surrounded by a mutex, and that you're going to need to
do your own memory management, including a bitmap of what
SSL-structure containing regions are in use and which are free and its
associated mutex.)
2. copy the SSL object (memcpy?) into shared memory region and then use this
object
in further SSL_read and SSL_write.
I am not sure how to go about achieving approac 1. and am not sure if
approach 2. is
safe and guarenteed to wrok.
I don't know if there's anything that refers to the SSL object once
it's been created. If there are references to it, it's not safe to
move it.
Could you help me on this?
Could you suggest any other possible option that I might not have considered
yet.
Already done. :)
Thank you for your help.
You're most welcome.
-Kyle H
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager [EMAIL PROTECTED]
