[patch] Cleaning out my trees, proxy-ssl patch

["William A. Rowe, Jr." <wr...@rowe-clan.net>]

Folks, I brought this up on list and don't remember a response.

I'm wondering if we need to do this handshake before using one
of mod_proxy's SSL client streams.  I believe we do in the case
of connecting to ftps:// if we ever support it, due to the fact
that we will attempt to read off the welcome first, and that's
not possible till we start an empty INIT write at the client
to negotiate.

It's sat around in this tree too long for me to worry about again,
if someone else shares my concern, please catch.

Bill

Re: [patch] Cleaning out my trees, proxy-ssl patch

[Ruediger Pluem <rp...@apache.org>]

On 10/25/2007 06:24 PM, William A. Rowe, Jr. wrote:
> Plüm wrote:
>> Sorry, but I do not get the purpose of this patch.
>> Why reading from our *client* (regardless if it is SSL or not)
>> when the backend is SSL?
> 
> The original flaw, maybe long gone, is that mod_ssl implementation was
> pull; on first read handshake would occur.  The INIT blocking-flag was
> added when Doug (IIRC) noted that mod_ftp couldn't simply write to the
> client, the handshake wouldn't run properly.
> 
> INIT let us do an initial pull from the client of nothing, soliciting
> the SSL handshake before Ftp Welcome.

Sorry for still being confused, but I don't get what this has to do with
the client when the backend is SSL. I would understand that something like
this is needed if the proxied backend is SSL or the connection to our client is SSL.
I don't get why I need to read also from a non SSL client if the the connection
to the backend is SSL. Just to avoid confusion with the terms:

Client (e.g. browser) <--> httpd (proxy / reverse proxy) <--> backend server

So reading from an SSL backend as the first thing might make sense (haven't
thought this out further.

Regards

Rüdiger

Re: [patch] Cleaning out my trees, proxy-ssl patch

["William A. Rowe, Jr." <wr...@rowe-clan.net>]

Plüm wrote:
> Sorry, but I do not get the purpose of this patch.
> Why reading from our *client* (regardless if it is SSL or not)
> when the backend is SSL?

The original flaw, maybe long gone, is that mod_ssl implementation was
pull; on first read handshake would occur.  The INIT blocking-flag was
added when Doug (IIRC) noted that mod_ftp couldn't simply write to the
client, the handshake wouldn't run properly.

INIT let us do an initial pull from the client of nothing, soliciting
the SSL handshake before Ftp Welcome.

I guess I can replicate the issue by sending a echod Welcome string before
soliciting the first line of text; this should prove up if ssl still needs
the init flag.

Re: [patch] Cleaning out my trees, proxy-ssl patch

[Plüm, Rüdiger, VF-Group <ru...@vodafone.com>]

Sorry, but I do not get the purpose of this patch.
Why reading from our *client* (regardless if it is SSL or not)
when the backend is SSL?
Did you confuse c->input_filters and backend->connection->input_filters?

Regards

Rüdiger

> -----Ursprüngliche Nachricht-----
> Von: William A. Rowe, Jr. [mailto:wrowe@rowe-clan.net] 
> Gesendet: Mittwoch, 24. Oktober 2007 06:14
> An: dev@httpd.apache.org
> Betreff: [patch] Cleaning out my trees, proxy-ssl patch
> 
> 
> Folks, I brought this up on list and don't remember a response.
> 
> I'm wondering if we need to do this handshake before using one
> of mod_proxy's SSL client streams.  I believe we do in the case
> of connecting to ftps:// if we ever support it, due to the fact
> that we will attempt to read off the welcome first, and that's
> not possible till we start an empty INIT write at the client
> to negotiate.
> 
> It's sat around in this tree too long for me to worry about again,
> if someone else shares my concern, please catch.
> 
> Bill
>