Re: Host header checking too strict?

[Roy T. Fielding]

> On Jun 25, 2018, at 8:57 AM, William A Rowe Jr  wrote:
> 
> On Mon, Jun 25, 2018 at 5:31 AM, Joe Orton  > 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

  https://tools.ietf.org/html/rfc3986#section-3.2.2 


and 

  
https://httpwg.org/http-core/draft-ietf-httpbis-semantics-latest.html#header.host
 


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

  https://github.com/httpwg/http-core 

Cheers,

Roy

Re: svn commit: r1828926 - in /httpd/httpd/trunk: CHANGES docs/manual/mod/mod_proxy.xml include/ap_mmn.h modules/proxy/mod_proxy.c modules/proxy/mod_proxy.h modules/proxy/mod_proxy_http.c

[Eric Covener]

On Wed, Apr 11, 2018 at 4:05 PM Yann Ylavic  wrote:
>
> On Wed, Apr 11, 2018 at 9:14 PM, Eric Covener  wrote:
> >> --- httpd/httpd/trunk/modules/proxy/mod_proxy.h (original)
> >> +++ httpd/httpd/trunk/modules/proxy/mod_proxy.h Wed Apr 11 19:11:52 2018
> >> @@ -459,6 +459,8 @@ typedef struct {
> >>  char  secret[PROXY_WORKER_MAX_SECRET_SIZE]; /* authentication 
> >> secret (e.g. AJP13) */
> >>  char  upgrade[PROXY_WORKER_MAX_SCHEME_SIZE];/* upgrade protocol 
> >> used by mod_proxy_wstunnel */
> >>  char  hostname_ex[PROXY_RFC1035_HOSTNAME_SIZE];  /* RFC1035 
> >> compliant version of the remote backend address */
> >> +apr_size_t   response_field_size; /* Size of proxy response buffer in 
> >> bytes. */
> >> +unsigned int response_field_size_set:1;
> >>  } proxy_worker_shared;
> >
> >
> > If this is for trunk only, should I move the bit field up and call it
> > major?  I don't plan to backport it.
>
> Maybe the backport is needed to resolve PR 62196 altogether?
>
> > Whether I move it or not, should I reserve the next range of bytes after it?
>
> Would be nice to rearrange the struct for trunk/2.next.
> As for bitfields I'm not sure it helps reserving names for unused bits
> since we can't extend them in stable versions anyway (I wish we could
> given that it doesn't change any size/address and bits themselves have
> no address, but IIRC from an earlier discussion with Bill it's not an
> option)

Bill or Yann, do you remember the specific gotcha with setting aside
addl bits and re-using them later?

2.4.x currently has a single bit bitfield at the end of the server_rec.

-- 
Eric Covener
cove...@gmail.com

Re: post response hook

[Eric Covener]

On Mon, Jun 25, 2018 at 2:22 PM Alan Nilsson  wrote:
>
> Is there a hook that runs after a response is sent to client but before the 
> process (prefork execution model) is queued up to take another request?
>
> We have a module that, as part of its job, is to accept uploaded files and 
> stash them away at a special place.  I would like to add functionality such 
> that the uploaded file also gets sent to 1 or more other servers for backup 
> purposes.  However, I don't want the client to have to wait for all of those 
> distribution events before it gets told that everything is OK.  If there is 
> no hook that would work for this, is it safe to spawn a pthread to simply 
> send the file elsewhere then die?
>

Two simple options -- you can either use log_transaction or register a
cleanup on the request pool at any earlier request hook.

post response hook

[Alan Nilsson]

Is there a hook that runs after a response is sent to client but before the 
process (prefork execution model) is queued up to take another request?

We have a module that, as part of its job, is to accept uploaded files and 
stash them away at a special place.  I would like to add functionality such 
that the uploaded file also gets sent to 1 or more other servers for backup 
purposes.  However, I don't want the client to have to wait for all of those 
distribution events before it gets told that everything is OK.  If there is no 
hook that would work for this, is it safe to spawn a pthread to simply send the 
file elsewhere then die?

any suggestions welcome.

alan

Re: Host header checking too strict?

[William A Rowe Jr]

On Mon, Jun 25, 2018 at 5:31 AM, Joe Orton  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.

Re: svn commit: r1834255 - /httpd/httpd/branches/2.4.x/STATUS

[William A Rowe Jr]

Provided we know they were made by a native or conversant writer, I agree
with you.

There is the question of reflexively trustring google translate (automated
translate again translated automatically)... which would result in
nonsense...

But I believe we are safe in accepting these, knowing what we do of the
submittors and reviewers. Please keep in mind it is easy to embed offensive
text (as once happened) that is invisible to the google translate user or
non-native speaker.

Cheers,

Bill

On Sun, Jun 24, 2018 at 12:09 PM, Christophe Jaillet <
christophe.jail...@wanadoo.fr> wrote:

> Hi,
>
> I personally think that we should push these translations.
> I've google translated some of them, in each language, and they look great.
>
> Should we wait for a formal review by a native speaker, I fear that they
> will still wait on trunk for years.
>
> So, let it go live and expect feedback from a wider audience, should some
> adjustments be necessary.
>
> CJ
>
>
>
> Le 24/06/2018 à 19:06, jaillet...@apache.org a écrit :
>
>> Author: jailletc36
>> Date: Sun Jun 24 17:06:27 2018
>> New Revision: 1834255
>>
>> URL: http://svn.apache.org/viewvc?rev=1834255=rev
>> Log:
>> Propose
>>
>> I've only google translated some of the proposals, in each language, and
>> they look great.
>>
>> Modified:
>>  httpd/httpd/branches/2.4.x/STATUS
>>
>> Modified: httpd/httpd/branches/2.4.x/STATUS
>> URL: http://svn.apache.org/viewvc/httpd/httpd/branches/2.4.x/STAT
>> US?rev=1834255=1834254=1834255=diff
>> 
>> ==
>> --- httpd/httpd/branches/2.4.x/STATUS (original)
>> +++ httpd/httpd/branches/2.4.x/STATUS Sun Jun 24 17:06:27 2018
>> @@ -177,6 +177,13 @@ PATCHES PROPOSED TO BACKPORT FROM TRUNK:
>>2.4.x patch: trunk works (modulo CHANGES in 2.4)
>>+1: jim, rpluem
>>   +  *) Add ru, zh-cn and zh-tw translations of errordocs.
>> + trunk patch: http://svn.apache.org/r1817175
>> +  http://svn.apache.org/r1831800
>> + 2.4.x patch: trunk works + CHANGES entry in r1834254
>> +  svn merge -c 1817175,1831800 ^/httpd/httpd/trunk .
>> + +1: jailletc36
>> +
>>   PATCHES/ISSUES THAT ARE BEING WORKED
>> [ New entries should be added at the START of the list ]
>>
>>
>

Re: Host header checking too strict?

[Joe Orton]

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.

Regards, Joe

AW: Host header checking too strict?

[Plüm , Rüdiger , Vodafone Group]

> -Ursprüngliche Nachricht-
> Von: Eric Covener 
> Gesendet: Freitag, 22. Juni 2018 23:21
> An: Apache HTTP Server Development List 
> Betreff: Host header checking too strict?
> 
> 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?

Regards

Rüdiger