Andrew Sumner wrote: > Implementing openssl I've hit a wall. > I need to initiate SSL on the connection in the > listener, before the client sends the login packet as it > obviously shouldn't be sent in the clear.
> There's no way to pass the SSL objects to the new process, > so I've been trying to close the SSL session and initiate a > new one on the still-open socket from the worker process. This has ugly potential security problems. > To do this, the listener sends a packet to the client when > it starts the worker process, telling the client to shutdown > its SSL. The listener does the same (calls SSL_shutdown > then SSL_free). The worker process sends a packet in the clear > to the client on the socket (this works), then calls SSL_new, > BIO_new_socket, SSL_set_bio and SSL_accept. When the client > gets the packet in the clear from the worker process, it also > calls SSL_new, BIO_new_socket, SSL_set_bio and then SSL_connect. > So far so good, it all appears to work. Key word is appears to. This is exceptionally difficult to get right. The problem is that both ends must precisely agree on where the SSL connection ends in both half-duplex streams. There are ugly ways to fix this -- for example, send a bunch of 0xff bytes followed by an 0x00 byte and have each end ignore all 0xff bytes until it reads an 0x00 byte. But that's really, really yucky. The other possible way is to go with BIO pairs and encapsulate all the SSL data in a higher-level protocol that can separate the two SSL exchanges. Also very yucky. Here's another butt ugly solution -- in the first SSL connection, send the client a random 128-bit string. Then shutdown the connection. Have the client make a new connection, send the 128-bit string, and then negotiate SSL. When your server sees the 128-bit string, hand off the connection as an "already logged in" one. Yuck. > The client can then send messages to the server worker process > using SSL_write, and the worker receives them ok. However, > when the worker sends something to the client, nothing comes > through - SSL_read fails. > In summary, is there any way of closing an SSL session on a socket, then opening a brand new one? Yes, but that's usually a really bad solution. Here's a better one: Implement SSL in a separate process that accepts SSL connections from clients and makes local direct connections to the server. Continue to proxy the data. You can use an off-the-shelf proxy (such as sslproxy), modifying it only as/if needed. Clean, elegant, sensible. Alternatively, have the server process create a bidirectional socketpair and itself act as an SSL proxy. Hand the worker the plaintext end of that pair. DS ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org
