[PATCH] 1.3 TraceEnable [on|off|extended]

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

I've spent a large number of cycles investigating the Watchfire report 
(http://www.watchfire.com/resources/HTTP-Request-Smuggling.pdf) and
come up with a genuine reason to adopt the attached patch.

One advantage of TRACE is to determine exactly what the server thinks
it just saw.  This is ideal for walking requests through proxies.

Unfortunately, TRACE does not support request bodies(*) (RFC2616 9.8;
"A TRACE request MUST NOT include an entity."), so it turned out 
to be somewhat useless, initially.  Supporting such behavior on
a very explicit basis (for testing the server or proxies, etc), since
proved to be very helpful for me.  (*) Note that 1.3, 2.0 and trunk
all support TRACE request bodies on proxied connections, the attached
patch also addresses this error.

Finally, after reviewing the report, I'm now convinced there is some
legitimate reason to deny TRACE if the administrator chooses.  Although
I don't subscribe to security by obscurity, too much transparency can
sometimes be a useful thing for exploit tools.  I still laugh at the
premise that TRACE 'caused' the IE xss vulnerabilities, of course.
Note that TRACE is not mandatory per RFC 2616 (only GET, HEAD are.)

So the attached patch introduces the per-host directive

TraceEnable on|off|extended

where extended permits a message body, up to 64kb at the target server,
and of an unlimited size through a proxy server.  The default remains
'on', of course, denying a TRACE body request even via proxy.

Following the semantics of TRACE, the request body is returned to the
host verbatim as part of the response, following the headers, exactly
as sent.

Patches will follow for 2.0 and trunk.  I have several days of other
work to catch up on, so won't jump on this till Friday eve.  Comments
on this patch before I start would be appreciated.

Bill

Rev 1: [PATCH] 1.3 TraceEnable [on|off|extended]

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

The attached patch resolved the issue I noted below,


10.4.6 405 Method Not Allowed


requires an Allow header (I would presume, even if empty),
while 


10.5.2 501 Not Implemented states


   This is the appropriate response when the server does not
   recognize the request method and is not capable of supporting 
   it for any resource.

If 'ProxyEnable off' is set for a given host, the setting is
url-impotent, and does not vary.




At 12:52 PM 6/22/2005, William A. Rowe, Jr. wrote:

>FYI there is one small issue still.  The resulting Allow: <null>
>response to denied TRACE request.  TRACE doesn't go through the
>normal processing, so methods aren't added.  And since TRACE is
>denied, it's removed too.

At 08:56 AM 6/22/2005, William A. Rowe, Jr. wrote:
>I've spent a large number of cycles investigating the Watchfire report 
>(http://www.watchfire.com/resources/HTTP-Request-Smuggling.pdf) and
>come up with a genuine reason to adopt the attached patch.
>...
>So the attached patch introduces the per-host directive
>
>TraceEnable on|off|extended
>
>where extended permits a message body, up to 64kb at the target server,
>and of an unlimited size through a proxy server.  The default remains
>'on', of course, denying a TRACE body request even via proxy.
>
>Following the semantics of TRACE, the request body is returned to the
>host verbatim as part of the response, following the headers, exactly
>as sent.

Re: [PATCH] 1.3 TraceEnable [on|off|extended]

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

At 08:56 AM 6/22/2005, William A. Rowe, Jr. wrote:

>Unfortunately, TRACE does not support request bodies(*) (RFC2616 9.8;
>"A TRACE request MUST NOT include an entity."), so it turned out 
>to be somewhat useless, initially.

FYI there is one small issue still.  The resulting Allow: <null>
response to denied TRACE request.  TRACE doesn't go through the
normal processing, so methods aren't added.  And since TRACE is
denied, it's removed too.

Result - we should use UNKNOWN_METHOD rather than METHOD_NOT_ALLOWED
since the later requires an Allow: header.  And, omit empty Allow:

Bill

Re: REQUEST_CHUNKED_PASS Q for 2.x TraceEnable [on|off|extended]

[Justin Erenkrantz <ju...@erenkrantz.com>]

On Thu, Jun 23, 2005 at 08:59:12AM -0500, William A. Rowe, Jr. wrote:
> Does anyone see a reason not to resurrect REQUEST_CHUNKED_PASS?

I have no idea what you are talking about (your email is vague on context);
but we should certainly not reintroduce the kludges associated with
REQUEST_CHUNKED_PASS.  The ap_*_client code needs to go away.  -- justin

REQUEST_CHUNKED_PASS Q for 2.x TraceEnable [on|off|extended]

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

Does anyone see a reason not to resurrect REQUEST_CHUNKED_PASS?

The 'TraceEnable extended' semantics include the entire body
handshaking for bodies < 64kb (rejecting larger bodies as
memory hogs).  The body = REQUEST_CHUNKED_PASS; line ensures
that the user sees the entire conversation.

This appears gone from 2.x, but it remains useful if unfiltered.
In fact, using some sort of metadata bucket with text, flagging
the bucket as a chunk header, makes a certain sort of sense to me.

I'll work up a patch this weekend if there is no objection.

Bill