On 28 Oct 2000, Rich Salz <[EMAIL PROTECTED]> wrote:
> > 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.
OK, I had hoped there might be a way around it.
> 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.
I think rproxy might even be similar.
> 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.
That's a good pointer: I'll have to check it out.
I *think* Apache doesn't actually use the same session from more than
one process at the same time. It just caches them so that cypher
negotiation etc doesn't have to happen on every new socket.
Can you confirm whether reading from an SSL socket will cause data to
be written back even after session startup?
I had thought about giving each direction a socket of its own, so it
would look like FTP. But that creates all kinds of problems with
firewalls, etc.
> It's an interesting problem, I'd be glad to bring it up on openssl
> if nobody else volunteers.
Thanks, that would be good.
> As for licensing, the only requirement is to give credit...
Fine.
> If you just embed arcfour, what's your key management plan?
key = MD4(salt, user, password, possibly other stuff)
The salt is sent on each new connection; at the moment it's somewhat
predictable but should never repeat. The password is known to both
the server and client, but never sent in the clear.
So the key should never be reused, but we avoid having a key-exchange
mechanism.
--
Martin Pool, Linuxcare, Inc.
+61 2 6262 8990
[EMAIL PROTECTED], http://www.linuxcare.com/
Linuxcare. Support for the revolution.
PGP signature
