On Fri, Jul 30, 1999 at 08:15:01AM +0200, Holger Reif wrote:
>> What signals a key renegotiation during a SSL session? Do Nav/IE typically
>> renegotiate session keys?
> Yes, in case a client cret is requested later by the server
> (depending on the URL requested) and ibn case of Global
> ServerID (wrongly called 128_Bit certs)
In the former case, it's of course not the browser that initiates the
renegotatiation -- it's the SSL library that must be forced
- to initiate a new handshake,
- to insist on a new handshake,
- and not to accept an abbreviated handshake for the initial session
(to recap the evolution of this functionality in Apache-SSL and
mod_ssl).
>> Does OpenSSL handles this gracefully?
> It does.
Provided that, in the non-blocking case, the application program
correctly reacts to SSL_ERROR_WANT_READ and ..._WRITE, which not all
programs do. The TCP write buffer will usually have enough space to
avoid deadlocks, but the possibilty of a deadlock remains, and
otherwise you get busy waiting. (I'm not even sure that s_client is
correct in this respect, but it's to confusingly written to deeply
look into this issue.)
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
