httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From William A Rowe Jr <wr...@rowe-clan.net>
Subject Re: HttpProtocolOptions Directive
Date Tue, 28 Feb 2017 14:21:06 GMT
On Tue, Feb 28, 2017 at 2:50 AM, Pavel Reichl <reichl.pavel@gmail.com> wrote:
> Hello,
>
> I have a question regarding this new directive - HttpProtocolOptions and in
> particular its parameter Unsafe.
>
> From https://httpd.apache.org/docs/2.4/mod/core.html:
> ...Due to legacy modules, applications or custom user-agents which must be
> deprecated the Unsafe option has been added to revert to the legacy
> behaviors.
>
> What exactly are supported deprecated behaviors? I noticed some formats that
> worked in 2.4.23 but do not work in 2.4.25 even with Unsafe.
>
> Among others:
> * Only SP is now supported as separator in request line - but it used to
> work with TAB and some other white space as well. (Although more than one SP
> can still be used.)
> * Neither SP nor TAB are allowed between header name and colon.
>
> Can you please confirm that this is intended behavior?

Hi Pavel,

yes, some specific requirements which had been present since RFC 2068
(published 20 years ago last month) or mandated by the RFC7230 series
of specifications, were considered by the httpd project, in the form of either
an UnsafeWhitespace option or yet another legacy property of Unsafe.

The three which were resoundingly rejected for legacy preservation are the
two you mention, SP in the request line (other whitespace characters such
as carriage return, form feed and vertical tab had been equally acceptable),
as well as CR+LF being the only recognized line seperator, both of which
have been clearly required by the spec all the way back to RFC 2068, as
well as no whitespace following the header name before the colon which
is a MUST implement per RFC 7230.

All three of these avert demonstrated security vulnerabilities which may
split requests or responses when passing between HTTP proxies which
have a different tolerance or interpretation of whitespace. This in turn may
lead to cache pollution or information disclosure, similar to the lingering
risks posed by cloudbleed.

As stated in the docs for this directive; "the strict whitespace suggested
by [RFC7230] section 3.5 is enforced and cannot be relaxed."

Hope this clarifies any confusion for you.

Mime
View raw message