On Mon, Sep 14, 2009 at 01:49:23PM +1000, Andrew Sumner wrote:
> Darryl,
>
> Thanks for your detailed suggestions, especially:
>
> > 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).
>
> For some reason, adding that line before the shutdowns made all the
> difference - it now works perfectly.
With read-ahead, parts of the subsequent traffic may be consumed as part
of the SSL_shutdown(). It may be possible to do this with read-ahead
enabled via a half-duplex shutdown:
Client. Server.
-----------------------------------
STOPTLS message (assuming server can't refuse)
SSL_read() until
(SSL_get_shutdown(s)
& SSL_RECEIVED_SHUTDOWN)
SSL_shutdown() == 0
SSL_shutdown() == 1
SSL_read() until
(SSL_get_shutdown(s)
& SSL_RECEIVED_SHUTDOWN)
(assuming SSL_read() works
after SSL_SENT_SHUTDOWN).
SSL_shutdown() == 1
... at any time later ...
[optional STARTTLS message? possible STARTTLS response]
SSL_connect() SSL_accept()
Above, the server only consumes the client's "close notify", because
the client does not start the re-connect phase until it has consumed
the server's "close notify", and the client is the next one to send.
A plain-text STARTTLS and OK response may be useful to make sure both
sides are ready and willing to resume if the session is not resumed
immediately. An external session cache (need not be "shared memory")
is useful in a mature implementation of multi-session connections.
--
Viktor.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager majord...@openssl.org
