Re: Drop HttpProtocolOptions Unsafe from 2.later/3.0 httpd releases?

[Stefan Eissing]

> Am 14.09.2017 um 17:43 schrieb William A Rowe Jr :
> 
> On Thu, Sep 14, 2017 at 4:50 AM, Nick Kew  wrote:
>> On Wed, 13 Sep 2017 08:29:44 -0500
>> William A Rowe Jr  wrote:
>> 
>>> So moving forwards, can we stop accepting stuff that isn't HTTP/1.1 in
>>> our HTTP/1.1 server? Do we really want people to configure their
>>> server to speak "other"?
>> 
>> Did you mean to say "stop accepting ..."?
>> 
>>> I'm starting to collect https://wiki.apache.org/httpd/Applications
>>> based on searching google for instances where users have toggled
>>> HttpProtocolOptions Unsafe, in response to specific application
>>> behavior.
>> 
>> Perhaps a useful exercise, but could take us in to a bad cycle
>> of application workarounds that long-outlive the application
>> being fixed.
>> 
>>> From this list, we might decide to allow non-HTTP/1.1 input in
>>> specific cases, and perhaps have multiple grades of protocol
>>> correctness, as I first proposed.
>> 
>> You mean something like Options or AllowOverride?  Things that looked
>> like a good idea at the time but led to all sorts of issues as the
>> server evolved!
>> 
>> OK, perhaps that's unduly harsh: this will be less problematic to
>> maintain.  Are you enumerating cases?
> 
> I'm strictly taking a survey of reported conflicts with the newer
> HttpProtocolOptions Strict behaviors.
> 
> My goal isn't to work around them, simply find out their prevalence
> in order to make a binary decision over dropping all legacy GIGO
> behavior (actually, garbage in, as we have generally done a nice job
> of normalizing the request to the backend or response to the client,
> which is what leads to splitting/injection vectors.)
> 
> Tomcat and other servers and proxies are taking serious steps
> toward accepting only valid input. 2.next/3.0 won't be here for
> some time, leaving lots of chances for authors to fix the defects
> in the client or upstream/app server or custom clients.
> 
> My question is whether HttpProtocolOptions Unsafe is needed,
> beyond the 2.4.x lifespan of our project? Conversely, did Unsafe
> still block some inadvisable but tolerable requests or responses?
> That's the purpose of the wiki incompatibilities page.

+1 to giving applications the chance to make their case.

+1 to remove all Unsafe cruft from trunk. 

Personally, I'd be tempted to remove even more, all the 0.9 stuff, for example,
and make this into a 2.6.x release line. As a security focus release line for
a) people who do not need the backward complications
b) people who want to verify that their app/clients no longer need the compat 
code

-Stefan

Re: Drop HttpProtocolOptions Unsafe from 2.later/3.0 httpd releases?

[William A Rowe Jr]

On Thu, Sep 14, 2017 at 4:50 AM, Nick Kew  wrote:
> On Wed, 13 Sep 2017 08:29:44 -0500
> William A Rowe Jr  wrote:
>
>> So moving forwards, can we stop accepting stuff that isn't HTTP/1.1 in
>> our HTTP/1.1 server? Do we really want people to configure their
>> server to speak "other"?
>
> Did you mean to say "stop accepting ..."?
>
>> I'm starting to collect https://wiki.apache.org/httpd/Applications
>> based on searching google for instances where users have toggled
>> HttpProtocolOptions Unsafe, in response to specific application
>> behavior.
>
> Perhaps a useful exercise, but could take us in to a bad cycle
> of application workarounds that long-outlive the application
> being fixed.
>
>> From this list, we might decide to allow non-HTTP/1.1 input in
>> specific cases, and perhaps have multiple grades of protocol
>> correctness, as I first proposed.
>
> You mean something like Options or AllowOverride?  Things that looked
> like a good idea at the time but led to all sorts of issues as the
> server evolved!
>
> OK, perhaps that's unduly harsh: this will be less problematic to
> maintain.  Are you enumerating cases?

I'm strictly taking a survey of reported conflicts with the newer
HttpProtocolOptions Strict behaviors.

My goal isn't to work around them, simply find out their prevalence
in order to make a binary decision over dropping all legacy GIGO
behavior (actually, garbage in, as we have generally done a nice job
of normalizing the request to the backend or response to the client,
which is what leads to splitting/injection vectors.)

Tomcat and other servers and proxies are taking serious steps
toward accepting only valid input. 2.next/3.0 won't be here for
some time, leaving lots of chances for authors to fix the defects
in the client or upstream/app server or custom clients.

My question is whether HttpProtocolOptions Unsafe is needed,
beyond the 2.4.x lifespan of our project? Conversely, did Unsafe
still block some inadvisable but tolerable requests or responses?
That's the purpose of the wiki incompatibilities page.

Re: Drop HttpProtocolOptions Unsafe from 2.later/3.0 httpd releases?

[Nick Kew]

On Wed, 13 Sep 2017 08:29:44 -0500
William A Rowe Jr  wrote:

> So moving forwards, can we stop accepting stuff that isn't HTTP/1.1 in
> our HTTP/1.1 server? Do we really want people to configure their
> server to speak "other"?

Did you mean to say "stop accepting ..."?

> I'm starting to collect https://wiki.apache.org/httpd/Applications
> based on searching google for instances where users have toggled
> HttpProtocolOptions Unsafe, in response to specific application
> behavior.

Perhaps a useful exercise, but could take us in to a bad cycle
of application workarounds that long-outlive the application
being fixed.

> From this list, we might decide to allow non-HTTP/1.1 input in
> specific cases, and perhaps have multiple grades of protocol
> correctness, as I first proposed.

You mean something like Options or AllowOverride?  Things that looked
like a good idea at the time but led to all sorts of issues as the
server evolved!

OK, perhaps that's unduly harsh: this will be less problematic to
maintain.  Are you enumerating cases?

-- 
Nick Kew

Drop HttpProtocolOptions Unsafe from 2.later/3.0 httpd releases?

[William A Rowe Jr]

So moving forwards, can we stop accepting stuff that isn't HTTP/1.1 in
our HTTP/1.1 server? Do we really want people to configure their
server to speak "other"?

I'm starting to collect https://wiki.apache.org/httpd/Applications
based on searching google for instances where users have toggled
HttpProtocolOptions Unsafe, in response to specific application
behavior.

>From this list, we might decide to allow non-HTTP/1.1 input in
specific cases, and perhaps have multiple grades of protocol
correctness, as I first proposed. A trailing space, after the protocol
designation in the request line is one example of a rather
unambiguously safe incompatibility.