You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Brad Nicholes <BN...@novell.com> on 2004/12/08 17:10:12 UTC

Testing TLS Upgrade (was: Re: Patch for bug 18757 breaks TLS upgrade)

  FYI, if anybody else is interesting is testing the TLS upgrade
functionality, there is a small test utility
(http://www.apache.org/~bnicholes/tlsupgrade.c) that can be used to send
an upgradeable GET or POST request.

Brad

>>> BNICHOLES@novell.com Wednesday, December 08, 2004 9:01:22 AM >>>
  It may be a bit of a hack, but it seems reasonable to me.  The best
part is that it works.

+1

Brad

>>> jorton@redhat.com Wednesday, December 08, 2004 2:33:48 AM >>>
On Tue, Dec 07, 2004 at 05:14:40PM -0700, Brad Nicholes wrote:
>    OK, now that you have enabled upgrades for anything other than
> OPTIONS, I see the problem.  Even though there is a content-length
> included in the header, you are saying that the header is being sent
> encrypted but the content is not, correct?  And the reason for this
is
> because there is more than one filter stack that needs to be
modified?

Yes.  I think this fixes it, it's a bit of a hack though:

Index: modules/ssl/ssl_engine_io.c
===================================================================
--- modules/ssl/ssl_engine_io.c	(revision 111159)
+++ modules/ssl/ssl_engine_io.c	(working copy)
@@ -1184,22 +1184,26 @@
     apr_bucket *b;
     SSL *ssl;
 
-    /* Just remove the filter, if it doesn't work the first time, it
won't
-     * work at all for this request.
-     */
-    ap_remove_output_filter(f);
+    /* f->ctx is non-NULL after the first call to this filter: it's
+     * necessary to pass through directly to the connection
output_filters
+     * for the remainder of this request, since the SSL output filter
has
+     * not been added to r->output_filters for this request. */
+    if (f->ctx) {
+        return ap_pass_brigade(f->c->output_filters, bb);
+    }
 
-    /* No need to ensure that this is a server with optional SSL, the
filter
-     * is only inserted if that is true.
-     */
-
+    /* No need to ensure that this is a server with optional SSL, the
+     * filter is only inserted if that is true. */
     upgrade = apr_table_get(r->headers_in, "Upgrade");
     if (upgrade == NULL
         || strcmp(ap_getword(r->pool, &upgrade, ','), "TLS/1.0")) {
         /* "Upgrade: TLS/1.0, ..." header not found, don't do Upgrade
*/
+        ap_remove_output_filter(f);
         return ap_pass_brigade(f->next, bb);
     }
 
+    f->ctx = f; /* flag as non-NULL for subsequent passes */
+
     apr_table_unset(r->headers_out, "Upgrade");
 
     /* Send the interim 101 response. */
@@ -1245,7 +1249,6 @@
        pass the brigade off to the connection based output filters so
that the 
        request can complete encrypted */
     return ap_pass_brigade(f->c->output_filters, bb);
-
 }
 
 static apr_status_t ssl_io_filter_input(ap_filter_t *f,

Re: Testing TLS Upgrade (was: Re: Patch for bug 18757 breaks TLS upgrade)

Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
At 10:10 AM 12/8/2004, Brad Nicholes wrote:
>  FYI, if anybody else is interesting is testing the TLS upgrade
>functionality, there is a small test utility
>(http://www.apache.org/~bnicholes/tlsupgrade.c) that can be used to send
>an upgradeable GET or POST request.

It seems to me we can make ab.c TLS upgrade-aware by;

  1. recognizing the -s flag in conjunction with http: - that
     would set the ssl preference client-side.  (This would not
     alter the behavior of https:, or of -s without a scheme.)

  2. recognize upgrade-required and promote an http: connection
     to SSL when the server-side demands it.

Sane?

Bill