"Ralf S. Engelschall" wrote: > > In article <[EMAIL PROTECTED]> you >wrote: > > > Yeah, why can't you just keep a "low water mark" or something in the BIO? > > You need to handle renegotiations anywhere, and you need to handle > > bi-directional protocols... apache isn't the only app using openssl... or > > maybe I completely misunderstand the problem. > > > >> To be honest, this sounds like a bug in openssl... renegotiation is a > >> transport layer issue, the application layer shouldn't be aware of it > >> except perhaps via a cert checking hook, but certainly not as an odd bump > >> in the stream. For example, suppose the protocol you were wrapping was > >> IMAP, wouldn't you require this bsuck all over the place? > > > >> > For SSL renegotiation situations where POST methods are involved we have > >> > discovered that we need a way to transfer the pending POST data from OpenSSL's > >> > underlaying input buffer (a BIO) to Apache's buffer (a BUFF), but _without_ > >> > consuming it through the ap_gets/ap_read and friends functions. > >> > > >> > The intent is that this way the SSL BIO is empty and the renegotiation can be > >> > successfully done while after the renegotiation Apache's upper layer can > >> > resume the POST handling (in mod_cgi, etc.). > >> > > >> > So the question is: Is there an easy way to read the POST data into Apache's > >> > BUFF without consuming it. Or have we write an own ap_bsuck() function which > >> > does the trick? If yes, can it be based on existing ap_bxxx() functions or > >> > should it do the stuff directly? > > No, you're not misunderstanding the problem, of course. I'm myself still not > convinced what the _CORRECT_ solution is. I'm currently poking around to find > an easy solutions and I thought some ap_bsuck() function could solve it. But > you're right, it might be more a problem with OpenSSL's SSL BIO which seems to > not allow renegotiations while there is still pending data. Hmmm... at least > yesterday I've looked over our complete buff.c and it seems a ap_bsuck() > cannot be done in a general way, at least not when there is more pending > receive data than 4KB. So, this ap_bsuck() idea we can forget. Next I'll look > inside OpenSSL's SSL BIO... Seems to me that you have a fundamental problem: since the HTTP protocol doesn't pause in the right place, SSL can't rengotiate where you want it to. The sending application is just doing what it should (i.e. HTTP header+POST body). Any renegotiation based on the header will _have_ to be queued up behind the body. This is a design flaw in HTTP wrt SSL. There should be a phase between the header and the body where the server says "yes, go ahead", at which point SSL would renegotiate before proceeding. Fiddling to make it _look_ like it wasn't happening is a bad idea. This means that the POSTed data arrives under false pretences, appearing to be under a different regime from the one it really is. I'd say that the bottom line is you can't renegotiate on a POST, if you want to change the protection of the posted data. Cheers, Ben. -- http://www.apache-ssl.org/ben.html "My grandfather once told me that there are two kinds of people: those who work and those who take the credit. He told me to try to be in the first group; there was less competition there." - Indira Gandhi ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
