Andrew Sumner wrote:
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?
If hope I understand the problem correctly (from your original email and
the nature of the responses of others on the issue).
You can keep an underlying TCP connection and reuse it for different SSL
sessions (where each SSL session has exclusive use of the underlying TCP
socket while that SSL session is active/open). So TCP socket stays open
a long time and sequentially an SSL session is created over it, used,
then closed, then the socket becomes idle again and can be used to open
a new SSL session. Rinse, repeat.
You can't take an already open SSL session and hand it to another
process. Technically there is no reason why this can't be done
(theoretically) if OpenSSL could freeze the entire active SSL handle
state to a binary data blob, which was then conveyed to another process
to be thawed. Seems like a lot of work for someone to implement and
maybe not many users in need of it.
You may be able to take an already open TCP socket handle and hand it to
another process. Unix has a file descriptor passing mechanism to
achieve this, Windows I'm not so sure on and would like to know myself
if this is possible maybe tweaking handle ACLs and such ?
The underlying application protocol needs to either be a client/server
relationship (where the client is always in control of what happens
next, such as the STARTTLS/STOPTLS case).
You just need to understand how SSL_shutdown() works, you need to
perform a full shutdown where both ends acknowledge the session is over
in both directions and all further data until further notice is cleartext.
It may also be helpful to call SSL_set_read_ahead(ssl, 0) to disable
readahead optimization just before you issue the SSL_shutdown(ssl). So
that the only bytes read out of the socket are SSL protocol and any
bytes behind are ready to be picked up by your application (and not
accidentally eaten by OpenSSL library trying to bulk read data in to
optimize SSL_read() performance).
Of course if there is any kind of SSL protocol error (which should be a
rare occurrence) the easiest way out is to drop the socket and cleanup
your SSL library handles. Rather than try to have some way of
re-synchronize the application.
The SSL_shutdown() recently had a patch to fix a problem with
non-blocking I/O and some scenarios I had been able to observe where
data was not correctly flushed to the kernel/lower-layer from OpenSSL
during shutdown handling when trying to re-used the underlying data
channel for a future SSL session.
The SSL_shutdown() command once issued effectively closes the write half
of the bi-directional SSL stream, the other end's application should get
notification of this and issue its own SSL_shutdown() which closes the
write half of the bi-direction SSL stream (from the far end), then once
your local end get notification of receiving this (by SSL_shutdown(ssl)
returning 0) you know that it's safe to disconnect the socket/fd from
OpenSSL handle and cleanup SSL structure (while hanging onto the still
open socket/fd).
During your wait after having called SSL_shutdown(ssl) at least once and
you now wait for SSL_shutdown() to return 0. You should also attempt to
SSL_read() and discard any data read in (unless you really do have a use
for it), it maybe possible for the far end send application data and if
you don't do SSL_read() you will never see the "SSL shutdown packet"
that the SSL_shutdown() function is waiting for to be able to return 0.
This may happen with regular SMTP servers where the server end had a
connection idle timeout at exactly the same moment the client end issued
a SSL_shutdown(). Many SMTP server send some kind of "XXX Shutdown due
to idle timeout." message just before closing the socket. For many
client-server protocols however it is not usually possible for the
server end to spontaneously send some application data because the
client is usually in 100% control of what the server does (I suppose
IMAP4 can!).
Hope this helps,
Darryl
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager majord...@openssl.org
