Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
Message-Id: <s0485266.065@prv-mail20.provo.novell.com>
Date: Fri, 05 Mar 2004 10:11:43 -0700
From: "Brad Nicholes" <BNICHOLES@novell.com>
To: <wrowe@rowe-clan.net>
Cc: <dev@httpd.apache.org>
Subject: Re: mod_ssl TLS/SSL upgrade...
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

I would really like to get the TLS/SSL upgrade functionality into the
2.0.49 release.  If Sander is wanting to start the relase on Monday, I
would like to do whatever is easiest to get this patch in.  

Brad

Brad Nicholes
Senior Software Engineer
Novell, Inc., the leading provider of Net business solutions
http://www.novell.com 

>>> wrowe@rowe-clan.net Thursday, March 04, 2004 11:20:31 PM >>>
Brad I'm plus 1, especially if we can cause libwww to instigate this
connection
mode for httpd-test and prove that it behaves per the RFC convention.

But I have a better proposal - let us simply move back the entire
mod_ssl 2.1
back to 2.0.  Only binary compat issues would need review.  But too
many
good things have happened on 2.1 to this specific component.

I'll propose SSL-C and win32 build solutions I've adopted for
Covalent's
build farm, over the next few days into 2.1.  note that the 2.1 rewrite
of the
autoconf .m4 stuff made thins much worse - I use a simple hack on top
of the 2.0 build scripts.

When we declare 2.1 baked, we should shift that module back :)  My QA
folks
have done extensive work wrt 2.1 (up to the last two weeks of rapid
patches) 
and have found it very well suited to build under 2.0.48, compared to
the 2.0
flavor.

Bill

At 10:08 PM 3/4/2004, Brad Nicholes wrote:
>   I would like to resurrect an old discussion.  About a year and
half
>ago rbb and wrowe committed a patch for mod_ssl to provide the
SSLEngine
>upgrade capability.  It seems that one of the reasons for not back
>porting it to the 2.0 tree was because there weren't really any
clients
>that supported it.  Well I know of at least one now which is Novell's
>iPrint client and I suspect that there may be others out there.  Does
>anyone see any major issues with backporting this functionality to
2.0? 
>If not then I would like to propose it for back port and see if we
can
>get it done.  The attached patch can be applied to the 2.0 branch. 
HEAD
>already contains all of the patches.  Here
>(http://www.apache.org/~bnicholes/wget_tls_prelim-1.8.2.tar.gz)is a
>hacked version of wget that is able to test the functionality. 
Invoke
>wget with the -u parameter to allow it to request the TLS/SSL
upgraded
>connection.
>
>Brad
>
>
>
>At 11:46 AM 10/15/2002, rbb@apache.org wrote:
>[snip]
>>The second is SSL upgrade.  I have the patches, they haven't been
>>committed yet.  I have attached them at the bottom of this message. 
>The
>>reason they haven't been committed, is that I don't have a client to
>test
>>them with, and I haven't had time to create one.  The responses are
>>correct I have checked them in plain text.  The place that bugs most
>>likely exist, is the actual upgrade code that does the handshake. 
>This is
>>an important feature, and I would really like to see it in 2.0.
>
>I see a couple of very important aspects to this patch:
>
>1) we must have an implementation of connection: upgrade for libwww,
>since
>   that is the mechanism we use for httpd-test/perl-framework.  I
don't
>have 
>   such a fix, so I'm just asking the community if anyone has
explored
>that 
>   avenue.
>
>2) it has to be maintained.  I've looked at this patch, it appears
>quite correct.
>   I'm going to begin working on applying it to cvs HEAD.  I'm not
>concerned
>   about it quickly appearing in 2.0 since there are no clients right
>now.  I'm
>   much more concerned about it's availability once clients can
support
>it.
>
>3) right now, the ssl code (ssl_engine_io) was already pretty heavily
>refactored.
>   The patch wasn't easy to apply.  We are discussing other
>refactorings that
>   will make SSL much simpler to follow and far less error-prone. 
>Those will
>   effectively invalidate the effort Ryan has already invested.
>
>My proposed solution is to review the patch and apply it to cvs HEAD.

>Get it
>committed.  Of course there are no test suites right now, and there
>won't be
>for a little while yet.  But once the code exists, it will be simpler
>to keep the
>SSL upgrade facility maintained, and debug it as the clients become
>available
>(most especially, libwww exercises through perl-framework.)
>
>Any disagreement?
>
>The current patch that applies to cvs HEAD is attached.
>
>Bill
>
>
>Brad Nicholes
>Senior Software Engineer
>Novell, Inc., the leading provider of Net business solutions
>http://www.novell.com