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