httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ben Laurie <>
Subject Re: BUFF question: sucking data without consuming
Date Tue, 27 Jul 1999 16:29:46 GMT
"Ralf S. Engelschall" wrote:
> In article <> you wrote:
> > "Ralf S. Engelschall" wrote:
> >>
> >> 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
> >> 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.
> That's exactly the technical point, yes.
> But let us talk about this even more. Who says that the client who sends the
> request consisting of HTTP-header+POST-body actually can _expect_ to see the
> renegotiation between HTTP-header and POST-body? Sure, it would be useful for
> security reasons (e.g. the POST data can already use a stronger cipher than
> the HTTP-header, etc.). But I've to admit that I see no _requirement_ for us
> to fulfill this _expectation_ of the client (when we could do it easily, we
> would be happy to do it this way, but as it looks, the renegotiation cannot be
> done such early and it nevertheless it should be acceptable this way).
> When the client sends HTTP-header+POST-body and the server is configured to
> renegotiate on a per-directory basis, IMHO the client has to expect that the
> renegotiation can occur at any time: immediately after the GET was read (the
> first possible time), after the headers and \r\n\r\n were read (the current
> attempt) or at last after the POST-body was read (the only way it technically
> works correctly).
> So, to make my point of view clear: Technically the current approach of the
> SSL renegotiation after the HTTP headers and before the POST body was read
> doesn't work as we've discovered. But because I personally see no struct
> requirement that it has to work this way, it should be fully acceptable when
> the server performs the renegotiation after _both_ HTTP headers _and_ POST
> body were read. Sure, one has to document this clearly to make sure that
> people do not think their POST data is already secured with the per-URL SSL
> configuration. But that's all IMHO. It's more a matter of documentation and
> understanding, isn't it?

Indeed. Well, like I say, it is a deficiency in HTTP, but not one we can
work around IMO.

> > 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.
> Yes. Ok, with HTTP chunking this could be done, I think. But it's then even
> more complex to handle this situation for the SSL module, of course.
> > 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.
> Hmmm... yes, the problem is that Apache doesn't suck in the whole request,
> only the HTTP headers. The POST data is pending until mod_cgi (or a similar
> module) read it. But then it's too late for an SSL module, of course.  So I
> think the only chance for the SSL module is to either say "no chance" or suck
> in the pending data first, then renegotiate new parameters and then pass the
> data to mod_cgi and friends.

No, I'd say the problem is that you are renegotiating at the wrong
moment. You should renegotiate just before the response is sent.

> > 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.
> Correct! That's what I meant by documentation above. People have to understand
> that this is not possible. Point. When they want that their POST body is
> already protected by a strong cipher or by whatever stronger requirements,
> these have to be already renegotiated by the initial SSL/TLS handshake. When
> they want to use POST and per-dir renegotiations they _have_ to accept that
> their POST data cannot be protect with the reconfigured parameters - only the
> response can.





"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

View raw message