On Fri, Jul 23, 1999, Matthias Loepfe wrote:

> > Interestingly enough, I found the exact same problem this morning. I'm
> > just writing our first cgi to require client certificates, and if the form
> > to be submitted is a get to the GET method, all is fine. Set it to post,
> > and I get an I/O error on the browser. My ssl_engine_log has the following
> > entries :
> 
> I had the same Problem and found the following:
> 
> It does happen if a dynamic SSL session renegotiation is requested because
> a Location has a different SSL configuration than the virtual host.
> 
> What happen is that the renegotiation gets not started, that means the 
> 'Server hello' will not be sent, because not all of the reveived bytes gets
> consumed by the upper (apache) layer. 

Is this a limitation of OpenSSL's BIO or which part creates this restriction,
Matthias? You mean mod_ssl's 

    SSL_renegotiate(ssl);
    SSL_do_handshake(ssl);

calls do nothing (i.e. does not _OUTPUT_ anything) unless the underlying BIO
of the SSL session has no more buffered _INPUT_ data? Hmmm... strange.
Actually AFAIK SSL/TLS specs say that SSL/TLS messages have higher priority
than application data. And I also don't understand why the INPUT side of the
buffer is important for the OUTPUT side.

> This does not happen with GET requests,
> because there is (normally) no request body, and the header bytes will all
> be consumed before the renegotiation gets triggerd.

Correct, good catch! Yes, that really seems to be the difference.

> You can easily see this in the ssl_engine_log if you set the loglevel to 
> trace.
> 
> This is probably not that easy to fix, especially if the body gets transfered
> in junked mode. Before a renegotiation can be triggered, the bytes already
> in the SSL receive buffer has to be 'transfered' to the apache request 
> receive buffer.

Hmmm... any clue how we can achieve this? I think we need an ap_bsuck()
function in Apache's buff.c which sucks in the data from the SSL BIO, right?

                                       Ralf S. Engelschall
                                       [EMAIL PROTECTED]
                                       www.engelschall.com

______________________________________________________________________
Apache Interface to OpenSSL (mod_ssl)                   www.modssl.org
User Support Mailing List                      [EMAIL PROTECTED]
Automated List Manager                            [EMAIL PROTECTED]

Reply via email to