Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
Date: Wed, 3 Oct 2001 08:28:06 -0700
From: Justin Erenkrantz <jerenkrantz@ebuilt.com>
To: dev@httpd.apache.org
Subject: Re: mod_ssl update...
Message-ID: <20011003082806.F21545@ebuilt.com>
References: <A5374D237E78D41195810090279CC91A05602DA7@xcup04.cup.hp.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <A5374D237E78D41195810090279CC91A05602DA7@xcup04.cup.hp.com>
User-Agent: Mutt/1.3.22.1i

On Wed, Oct 03, 2001 at 01:30:02AM -0700, MATHIHALLI,MADHUSUDAN (HP-Cupertino,ex1) wrote:
> You're right.. the bulk of the SSL communication logic is done in churn()..
> The logic basically reads the user data from the filter, gives it to OpenSSL
> thru' the BIO routines, and whatever is output by openssl is picked up thru'
> the BIO interfaces and put on to the output queue.. I'm not clear what you
> mean by "separate input and output"..

Most of the other filters have their logic separated by input and
output.  mod_ssl combines them into one function.  I think that
it makes sense to split it out so that input is only handled by
one function and output is handled by another function.  I'm not
sure why we have one function attempting to handle input/output.
Is there a reason why churn() must exist?  Input and output are
not related to each other.

I'm not familiar with the BIO_* routines (when I was writing the
SSL code for flood, the BIO_* routines did not work for me).  So,
I had it handle reading from the socket itself - and that seemed
to work out well.

> I don't think so..As long as we can gather the *full client data* and pass
> it across, OpenSSL is happy.. The catch here is to capture all the data
> that's sent by the client, and not to break it into small chunks/pieces.

What the real deal is that OpenSSL was assumming that it'd get the
socket bucket back from the core filter and it'd be able to do whatever
it wanted with it.  That's not possible anymore.

If it is possible to have the core do the heavy lifting (i.e. reading
from the socket), that is preferred.  I'm just not sure how mod_ssl
is reading from the socket at all.  It calls ap_get_brigade *and*
SSL_read - that is a violation of the input filter semantics.  Either
it reads from the socket on its own or it relies on the core for all
of the input.

> It's definitely possible to use the SSL_* functions - but, then we'll have
> to expose the socketfd's et al.. Also, it'd be deviating from the other
> modules of apache, where the filters are *almost* forced to be used. I'd
> prefer to have the ap_get_brigade_* functionality to read/write the data
> from the socket.

Yes, I'd prefer it to rely on core, but there are things like *readbytes
0 that are completely bogus in the core with SSL.  That's why I'm not 
sure we can use the core filter anymore.  

Since all of the data in the socket is encrypted, if readbytes == 0 is 
sent, it means to read a line of input data which is now bogus because 
the core (since it can't read the actual socket information) can't
determine when a line of input data is read.  Only mod_ssl has the
logic to decrypt the packet information.  

(And look at flood to see how you get the socketfd back from the
apr_socket_t...)  -- justin