> However, I don't think SSL will cope with two fork'd processes trying
> to do SSL simultaneously, because the library assumes complete control
> over the local end of the socket.
OpenSSL doesn't *have* to work that way, it's just that the default
implementation that most people use works that way. You don't need to have
sockets at all, just a "BIO" object that has methods to read/write/flush.
Look through the openssl-users archives, particularly for recent messages from
Geoff Thorpe. You write it as co-routines, basically, whenever you have I/O
you cycle through a couple of times until OpenSSL says it no longer has an I/O
for you to add in. :) That's not a great description -- if you've ever done
GSSAPI programming it's not unlike that.
Having said that, the trick of sharing the context across forked processes is
solved -- Apache does it -- but sharing session keys across multiple forked
TCP sockets, I dunno -- that seems more than a little harder.
It's an interesting problem, I'd be glad to bring it up on openssl if nobody
else volunteers. As for licensing, the only requirement is to give credit...
If you just embed arcfour, what's your key management plan?
/r$
