On Mon, Aug 13, 2001 at 02:32:09PM +0200, Lutz Jaenicke wrote:
> On Sun, Aug 12, 2001 at 07:32:25AM -0400, Avery Fay wrote:
> > I've been given a task that a previous employee at our company was
> > unable to accomplish. Before I start I would like to ask if it is even
> > possible.
> >
> > What I need to do:
> >
> > 1.) start a ssl session
> > 2.) send / receive some data
> > 3.) stop that session but keep the tcp / ip connection open
> > 4.) start a new ssl session using that tcp / ip connection
> > 5.) send / receive more data
> > 6.) close the connection
> >
> > Both sides of the connection will know when to start the new ssl
> > session. The reason I need to do this is somewhat complicated, but a
> > hard requirement is that I have to keep the tcp / ip connection open and
> > I must start a new ssl session. Can this be done? Are there any problem
> > areas that I may run into? Thanks for your time and please CC me because
> > I am not subscribed to the list (but may be soon if this is possible).
>
> I think it should be possible to realize this.
> The problem may be in the correct shutdown of the SSL layer. Both the
> client and the server must stay synchronized.
> With respect to the current realization of SSL_shutdown() (which tends
> to be strange):
> The first call to SSL_shutdown() will send the "alert close" to the peer,
> but does not wait for the peer to send its closure alert.
> * Peer 1:
> - SSL_shutdown(): send "close alert"
> (SSL_shutdown() should return 0!?)
> * Peer 2:
> - receives "close alert"
> - SSL_shutdown(): send "close alert".
> * SSL_shutdown() should return 1.
> * The SSL connection on Peer 2 is now closed properly, but there is
> still a "close alert" on the wire on its way to "peer 1".
> This package on the wire now must be processed by "peer 1", so that
> both parties are in sync again.
> * Peer 1:
> - Call SSL_shutdown() again, in order to process the "close alert" on
> the wire.
> SSL_shutdown() should now return 1.
Just thought I'd give you some results from my own experiments with
shutdown. I'm using non-blocking sockets. All the time. Of course, if it
is quite okay that the client can go to blocking mode during the shutdown
+ new session, then I don't think SSL_shutdown() will return until the
closure alerts have been exchanged completely.
That doesn't work on the server side obviously, since you can have many
clients that you don't want to put on hold :-)
Here's what I do when multiplexing using select:
When one of the sides want to disconnect, they call SSL_shutdown(). If the
return value is 1, everything is just great, otherwise we flag a
sent_shutdown variable. Whenever you get SSL_ZERO_RETURN_ERROR on an
SSL_read() you got a closure message from the other side. Check your
sent_shutdown flag, if it's true everything is great, otherwise we do
SSL_shutdown() and then we can proceed normally.
So Far<tm> this has worked just fine. Can you find a flaw in my thinking?
Cheers,
Martin
--
Martin Sjögren
[EMAIL PROTECTED] ICQ : 41245059
Phone: +46 (0)31 405242 Cell: +46 (0)739 169191
GPG key: http://www.strakt.com/~martin/gpg.html
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
