httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ben Laurie <...@algroup.co.uk>
Subject Re: BUFF question: sucking data without consuming
Date Tue, 27 Jul 1999 10:05:53 GMT
"Ralf S. Engelschall" wrote:
> 
> In article <Pine.LNX.3.96dg4.990725124017.23790A-100000@twinlark.arctic.org> 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

Mime
View raw message