Re: Host header checking too strict?
This was implemented last year in 2.4.24. Much has happened and just a
few strugglers including I, had to deal with it, it seems.
I remember I mentioned the CVE at work and that seemed enough for
everyone to accept the change and nobody proposes _ in new names since
then. IIRC "httpprocotoloptions unsafe" could override this already.
Hey Eric, we even had a discussion about this at IRC, remember? :)
So what is the option we would offer instead?
El mar., 26 jun. 2018 a las 0:19, Roy T. Fielding
> On Jun 25, 2018, at 8:57 AM, William A Rowe Jr <wrowe@xxxxxxxxxxxxx> wrote:
> On Mon, Jun 25, 2018 at 5:31 AM, Joe Orton <jorton@xxxxxxxxxx> wrote:
>> On Fri, Jun 22, 2018 at 05:21:08PM -0400, Eric Covener wrote:
>> > After CVE-2016-8743 we only accept hostnames that are valid in DNS,
>> > which notably excludes underscores. But it seems like 7230 does not
>> > require HTTP Host: to use a DNS registry, and excluding '_' should
>> > have broken IDN (punycode) international domain names.
>> > Meanwhile I have seen several reports of e.g. departmental servers or
>> > proxypreservehost=off-like failures with hostnames w/ underscores.
>> > Should we be more tolerant here, or offer an option?
>> > [ ] No
>> > [X] Just underscores, which seems to come up alot?
>> Yup, we had Fedora users complain about this as well after 2.6.25, +1
>> for underscores in hostnames allowed by default.
> I'll concur, I see no problem "violating" the spec in this single respect.
> Note that the same is not true of, say, http field names. There, ambiguity
> between - and _ due to CGI is an actual problem.
> The spec is at
> Whatever we are doing, underscore is allowed by the spec. DNS is irrelevant here
> because hostnames are not limited to DNS names.
> It is reasonable for us to limit Host to be the set of allowed virtual hosts we are
> willing to match, so we can certainly exclude the weird delimiters, but we
> don't want to prevent access to hosts we allow to be configured.
> BTW, note that the second link above is to the current editors' draft of HTTP,
> which is being revised now. If anyone wants to reduce the grammar here or
> elsewhere, now is the time to make it an issue at
#httpd help at Freenode