Re: starting new ssl session on previous ssl socket
On 08/12/01 07:32 AM, Avery Fay sat at the `puter and typed: Hello, 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). Avery Fay How about SSL_renegotiate()? Check the archives over the last week, Eric Rescorla dealt with a rehandshaking question recently, and mentioned an article he is working on for Linux Journal. If it can be done, I'd imagine that is the way to do it. HTH Lou -- Louis LeBlanc [EMAIL PROTECTED] Fully Funded Hobbyist, KeySlapper Extrordinaire :) http://acadia.ne.mediaone.net ԿԬ We can defeat gravity. The problem is the paperwork involved. __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: starting new ssl session on previous ssl socket
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. After this processing has succeeded, both parties should be in sync and a new SSL handshake should be possible. Rule of thumb: call SSL_shutdown() twice, if the first call did not succeed... Best regards, Lutz PS. The manual page for SSL_shutdown() does not reflect this behaviour properly. I have to fix this... -- Lutz Jaenicke [EMAIL PROTECTED] BTU Cottbus http://www.aet.TU-Cottbus.DE/personen/jaenicke/ Lehrstuhl Allgemeine Elektrotechnik Tel. +49 355 69-4129 Universitaetsplatz 3-4, D-03044 Cottbus Fax. +49 355 69-4153 __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: starting new ssl session on previous ssl socket
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 Fartm 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 405242Cell: +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]
