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
