and what if i detach (maybe fork) this process from the main one?
in such case, the problem is how to return the upgraded socket object from child to main one?

i know, it sounds somewhat insane (in case of fork)...

i'm not familiar with threads, however maybe it could help...
i don't know.
could it?

thanks!

I hope you don't mind me necroing this old topic but I solved the exact same problem successfully by forking the process this way:

my $pid = open(my $pipe, "-|");

In the child process I then upgrade the client socket to SSL, contact the server and relay data between the two. Whatever info I need to send back to the parent process I can just print to STDOUT. The parent process has a very tight main loop switching between accept()'ing new connections and using IO::Select to determine which $pipe sockets are ready for non-blocking reads.

In another project of mine (not SSL related) I went a little further and established a plain two-way socket between the two processes and used non-blocking/select based sysread/syswrite on those as well. Non-blocking sockets between forked processes are actually a lot of fun :-)

Admittedly, the forking model does have its limitations when it comes to scaling, but it's relatively simple to get up and running and I found it quite sufficient for doing simple traffic inspection.

-- FloydATC

I got 99 problems, most of them have to do with printers.

> in such case, the problem is how to return the upgraded socket object from child to main one?

Since SSL is a user-space layer on top of the kernel TCP socket there is no sane way to upgrade the socket to SSL in a child and then continue with the upgraded socket in the parent process.
You might try with threads but the OpenSSL FAQ clearly states that a single SSL connection should not be used from within multiple threads at the same time. I'm not sure if this applies in this case too where you are using different SSL connections but the same SSL context object.