Bug report for Apache httpd-2 [2017/01/15]

2017-01-14 Thread bugzilla 
+---+
| Bugzilla Bug ID   |
| +-+
| | Status: UNC=Unconfirmed NEW=New ASS=Assigned|
| | OPN=ReopenedVER=Verified(Skipped Closed/Resolved)   |
| |   +-+
| |   | Severity: BLK=Blocker CRI=Critical  REG=Regression  MAJ=Major   |
| |   |   MIN=Minor   NOR=NormalENH=Enhancement TRV=Trivial |
| |   |   +-+
| |   |   | Date Posted |
| |   |   |  +--+
| |   |   |  | Description  |
| |   |   |  |  |
| 8713|Inf|Min|2002-05-01|No Errorlog on PROPFIND/Depth:Infinity|
| 8867|Opn|Cri|2002-05-07|exports.c generation fails when using a symlink to|
|10747|New|Maj|2002-07-12|ftp SIZE command and 'smart' ftp servers results i|
|11294|New|Enh|2002-07-30|desired vhost_alias option|
|11580|Opn|Enh|2002-08-09|generate Content-Location headers |
|12033|Opn|Nor|2002-08-26|Graceful restart immediately result in [warn] long|
|13599|Inf|Nor|2002-10-14|autoindex formating broken for multibyte sequences|
|13661|Ass|Enh|2002-10-15|Apache cannot not handle dynamic IP reallocation  |
|14104|Opn|Enh|2002-10-30|not documented: must restart server to load new CR|
|14496|New|Enh|2002-11-13|Cannot upgrade any version on Windows. Must uninst|
|14922|Inf|Enh|2002-11-28| is currently hardcoded to 'apache2'  |
|15719|Inf|Nor|2002-12-30|WebDAV MOVE to destination URI which is content-ne|
|16761|Inf|Nor|2003-02-04|CustomLog with pipe spawns process during config  |
|16811|Ass|Maj|2003-02-05|mod_autoindex always return webpages in UTF-8.|
|17107|New|Min|2003-02-16|Windows should not install printenv   |
|17114|New|Enh|2003-02-17|Please add strip and install-strip targets to Make|
|17244|Ass|Nor|2003-02-20|./configure --help gives false information regardi|
|17497|Opn|Nor|2003-02-27|mod_mime_magic generates incorrect response header|
|18325|New|Enh|2003-03-25|PAM support for suEXEC|
|18334|Inf|Cri|2003-03-25|Server crashes when authenticating users against L|
|19670|New|Enh|2003-05-05|content type header supplied upon PUT is thrown aw|
|20036|Ass|Nor|2003-05-19|Trailing Dots stripped from PATH_INFO environment |
|21260|New|Nor|2003-07-02|CacheMaxExpire directive not enforced !   |
|21533|Ass|Cri|2003-07-11|Multiple levels of htacces files can cause mod_aut|
|22484|Opn|Maj|2003-08-16|semaphore problem takes httpd down|
|22686|Opn|Nor|2003-08-25|ab: apr_poll: The timeout specified has expired (7|
|22898|Opn|Nor|2003-09-02|nph scripts with two HTTP header  |
|23167|Inf|Cri|2003-09-14|--enable-layout never goes to apr apr-util|
|23181|New|Nor|2003-09-15|Status 304 (Not modified) and chunking leads to an|
|23238|New|Cri|2003-09-18|non-async-signal-safe operations from signal handl|
|23330|New|Enh|2003-09-22|Enhance ApacheMonitor to view and control Tomcat s|
|23911|Opn|Cri|2003-10-18|CGI processes left defunct/zombie under 2.0.54|
|24031|New|Enh|2003-10-23|Passphrase protected private key in SSLProxyMachin|
|24095|Opn|Cri|2003-10-24|ERROR "Parent: child process exited with status 32|
|24437|Opn|Nor|2003-11-05|mod_auth_ldap doubly-escapes backslash (\) charact|
|24890|Opn|Nor|2003-11-21|Apache config parser should not be local aware ( g|
|25014|New|Enh|2003-11-26|A flexible interface for mod_log_config   |
|25201|New|Enh|2003-12-04|Provide Cache Purge operation |
|25240|Inf|Enh|2003-12-05|SSL Library Error: 336105671 logged as information|
|25435|New|Enh|2003-12-11|sethandler and directoryindex not playing nice|
|25469|Opn|Enh|2003-12-12|create AuthRoot for defining paths to auth files  |
|25484|Ass|Nor|2003-12-12|Non-service Apache cannot be stopped in WinXP |
|25543|Inf|Nor|2003-12-15|mod_proxy_ajp overwrites existing response headers|
|25667|New|Nor|2003-12-19|Memory leak in function ssl_scache_dbm_retrieve().|
|25863|New|Enh|2004-01-02|new per-host initialization hooks |
|26005|New|Nor|2004-01-08|SERVER_NAME incorrect when using IPv6 address in U|
|26142|New|Maj|2004-01-14|EnableSendFile Off for Windows XP Home|
|26153|Opn|Cri|2004-01-15|Apache cygwin directory traversal vulnerability   |
|26368|New|Min|2004-01-23|File extensions in AddDescription treated as part |
|26446|New|Nor|2004-01-26|flush buckets followed by eos bucket emit multiple|
|26478|New|Enh|2004-01-28|mod_dav does not expose a method for setting the D|

Re: mod_lets-encrypt

2017-01-14 Thread William A Rowe Jr 
On Sat, Jan 14, 2017 at 1:05 PM, Stefan Sperling  wrote:
> On Sat, Jan 14, 2017 at 07:15:29PM +0100, Dirk-Willem van Gulik wrote:
>> In fact - that may be a nice feature - an, essential, empheral port.
>
> Would that work for web servers behind firewalls?

Most configured in that scenario need pinholes. I'm not sure that a well
known but non-root port would be considered sufficiently secure by the
letsencrypt architects. Seems worth raising the original question, with
your firewall scenario in mind, and let their architects ponder the idea.

At the end of the day, only the one in control of those firewalls should
be respected by letsencrypt as the owner of the specific domain. That's
why the firewall is in front of their resources in the first place.

Obviously the actual port number isn't a valid security restriction in the
real world in the first place; there are plenty of ways to abuse a front
end firewall/load balancer behind the lines, and many appliances and
OS's don't require root or can be configured to permissively let other
accounts listen on particular low ports, and as long as you are physically
able to access the cables... but letsencrypt is not concerned with that.
It's simply that they are able to validate that you are in some way in control
of the target of the corresponding DNS A or  records.

Re: mod_lets-encrypt

2017-01-14 Thread William A Rowe Jr 
On Sat, Jan 14, 2017 at 12:15 PM, Dirk-Willem van Gulik
 wrote:
>
> On 14 Jan 2017, at 19:05, William A Rowe Jr  wrote:
>
> Any mod_letsencrypt can provision the certs but needs to do so
> while still root, before servicing requests (although there could be
> some bounce-step where the MPM begins satisfying requests,
> including the verification request necessary for letsencrypt.) We
> certainly don't want to parse any web response whatsoever while
> running as root.
>
> Some of this will be needed - we need to be root to bind to port 80 — as the
> protocol (in my reading) seems to demand it (now would be a good time to
> petition the draft to change this for a random higher port).
>
> In fact - that may be a nice feature - an, essential, empheral port.

My thinking was more along the lines that we fork off a process, much like
mod_cgid or mod_ftp does to handle low numbered ports. What is actually
handed across the domain socket or equivalent is structured simply enough
to not be harmed by an errant child process, or if needed by the server
earlier, then forked with the lesser run-as-httpd user permissions to speak
some predictable and strictly constructed message back up to the root parent
process.

It might be nice to our users if the cert/key isn't in the keystore,
that the server
starts anyways with a dummy cert, until it finally resolves to the
letsencrypt CA
server and completes that handshake. The server can respond to that child
process modifying the keystore and exiting by initiating a graceful restart to
begin serving traffic with the newly obtained cert/key material.

Somewhere in this equation lies accessor functions to mod_ssl to allow us
access to keystores. Which would be a very useful facility, well beyond just
letsencrypt. Whether those cert/key pairs live in ldap or some other place.
Imagine a small cluster, say 4 instances of httpd, where only one performs
the letsencrypt dance and the others search a memcache or other remote
resource for the resulting cert/key materials (locked down well, we would
hope.)

Re: mod_lets-encrypt

2017-01-14 Thread Stefan Sperling 
On Sat, Jan 14, 2017 at 07:15:29PM +0100, Dirk-Willem van Gulik wrote:
> In fact - that may be a nice feature - an, essential, empheral port.

Would that work for web servers behind firewalls?

Re: mod_lets-encrypt

2017-01-14 Thread Dirk-Willem van Gulik 

> On 14 Jan 2017, at 19:05, William A Rowe Jr  wrote:
> 
> On Sat, Jan 14, 2017 at 10:22 AM, Eric Covener  wrote:
>> On Sat, Jan 14, 2017 at 11:19 AM, Eric Covener  wrote:
>>> 
>>> I think if a feature/directive will turn on something that will write
>>> to configured keystores, it really shouldn't do or dictate much else.
>> 
>> Poorly phrased, but I think obtaining a cert should be separate from
>> things like further SSL configuration.
> 
> I think Dirk is suggesting that the core mod_ssl continues to exist, with
> sane defaults that require next to no specific directives other than to
> perhaps set the https protocol on port 443, and (I vote optionally) have
> a one line toggle for rewriting all port 80 requests to 443.
> 
> Note that h2 requests will continue to be honored on either port 80
> or 443, so this has to be crafted somewhat carefully.
> 
> I'm 100% in support of ensuring that mod_ssl runs with the most
> sensible choices in the most minimal config.
> 
> Any mod_letsencrypt can provision the certs but needs to do so
> while still root, before servicing requests (although there could be
> some bounce-step where the MPM begins satisfying requests,
> including the verification request necessary for letsencrypt.) We
> certainly don't want to parse any web response whatsoever while
> running as root.

Some of this will be needed - we need to be root to bind to port 80 — as the 
protocol (in my reading) seems to demand it (now would be a good time to 
petition the draft to change this for a random higher port).

In fact - that may be a nice feature - an, essential, empheral port.

And we will need to be able to respond to an HTTP request to a well known URL 
with the public key/token — and post that have some fork/pid be root enough to 
write a few things to safe places.

> I do believe the proposal should require a one line directive to
> enable this, particularly for the compiled-in static many modules
> build of httpd. It's shouldn't be simply a matter of loading some
> mod_letsencrypt without also some 'LetsEncrypt on" directive
> in the ssl vhost config.

The alternative is bundling a small shell script, like  stripped down
‘dehydrate’:

https://github.com/lukas2511/dehydrated/blob/master/dehydrated 


as a tool. And augment it with examples. But then you are back to square one.

Dw.

Re: mod_lets-encrypt

2017-01-14 Thread William A Rowe Jr 
On Sat, Jan 14, 2017 at 10:22 AM, Eric Covener  wrote:
> On Sat, Jan 14, 2017 at 11:19 AM, Eric Covener  wrote:
>>
>> I think if a feature/directive will turn on something that will write
>> to configured keystores, it really shouldn't do or dictate much else.
>
> Poorly phrased, but I think obtaining a cert should be separate from
> things like further SSL configuration.

I think Dirk is suggesting that the core mod_ssl continues to exist, with
sane defaults that require next to no specific directives other than to
perhaps set the https protocol on port 443, and (I vote optionally) have
a one line toggle for rewriting all port 80 requests to 443.

Note that h2 requests will continue to be honored on either port 80
or 443, so this has to be crafted somewhat carefully.

I'm 100% in support of ensuring that mod_ssl runs with the most
sensible choices in the most minimal config.

Any mod_letsencrypt can provision the certs but needs to do so
while still root, before servicing requests (although there could be
some bounce-step where the MPM begins satisfying requests,
including the verification request necessary for letsencrypt.) We
certainly don't want to parse any web response whatsoever while
running as root.

I do believe the proposal should require a one line directive to
enable this, particularly for the compiled-in static many modules
build of httpd. It's shouldn't be simply a matter of loading some
mod_letsencrypt without also some 'LetsEncrypt on" directive
in the ssl vhost config.

Re: mod_lets-encrypt

2017-01-14 Thread Eric Covener 
On Sat, Jan 14, 2017 at 11:19 AM, Eric Covener  wrote:
>
> I think if a feature/directive will turn on something that will write
> to configured keystores, it really shouldn't do or dictate much else.

Poorly phrased, but I think obtaining a cert should be separate from
things like further SSL configuration.

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

Re: mod_lets-encrypt

2017-01-14 Thread Eric Covener 
On Sat, Jan 14, 2017 at 10:43 AM, Dirk-Willem van Gulik
 wrote:
>
> Where this implies SSLEnable, a set of sane/best-practice. ‘A+’, set of
> baseline SSL directives w.r.t. OSCP stapling  and so on. And absolutely no
> further SSL statements in your vhost. And it implies that port 80 forwards
> to https. Perhaps disallow any port/listen stuff ?
>
> If you need SSL statements — then you are out of scope ? Is that fair ?

I think if a feature/directive will turn on something that will write
to configured keystores, it really shouldn't do or dictate much else.


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

Re: mod_lets-encrypt

2017-01-14 Thread Dirk-Willem van Gulik 
(reshuffled top post)

On 14 Jan 2017, at 16:07, Rich Bowen  wrote:
> On Jan 10, 2017 12:15 PM, "Jacob Champion"  > wrote:
> On 01/10/2017 08:35 AM, Dirk-Willem van Gulik wrote:
> Before I send someone into the woods - did anyone consider/do a quick
> ‘mod_lets_encrypt’ (with or without a persistent store) — that
> requires virtually no configuration ?
> 
> Considered? Yes. Back in August there was some discussion on this list with 
> Josh Aas. I don't know what the current status is.
..
> https://lists.apache.org/thread.html/ea902ae8e453b3a8d36345318fc74a54880d8bf14fed24e665c4b833@%3Cdev.httpd.apache.org%3E
>  
> 
...
> https://lists.apache.org/thread.html/27d1fce7d30d9e31e2472045c260e4f8dcefd300a731ff9e435a5d4a@%3Cdev.httpd.apache.org%3E
>  
> 
> I talked with him at linuxcon, but there's been no followup. I for one would 
> love to see this happen.

So it seems we currently pull in enough sundry into mod_ssl to barely need 
something as ‘big’ as:

https://github.com/kristapsdz/acme-client 

if we assume the HTTP method (only) — which makes sense if we assume that this 
module is first and foremost about zero configuration and convenience. 

By extend that also means we ‘trust’ ourselves and the user we start up as 
(prior to any fork, suid or chrooting).

So I think we can narrow this down a lot (I just had to put something like this 
into a simple XMPP system) - as anyone who wants to do something more complex 
can use the many scripts available or use ‘real’ CA request processes.

So we are talking about the configs which are as simple as

# Defaults to /var/httpd/acme-private or something like we do for 
Mutexes.
#
ACMEDir /var/db/httpd/acme-private


ACME automatic
…

Where this implies SSLEnable, a set of sane/best-practice. ‘A+’, set of 
baseline SSL directives w.r.t. OSCP stapling  and so on. And absolutely no 
further SSL statements in your vhost. And it implies that port 80 forwards to 
https. Perhaps disallow any port/listen stuff ?

If you need SSL statements — then you are out of scope ? Is that fair ?

Which reduces the footprint to:

-   fetching the ACME-CA-URLs on first run ever; on install —or— having 
these as part of the distribution.

=> Fair to assume we ship with the ACME CA url ?

-   pin the server.

-   reading -or- generating an RSA key & 0600 storing it in what we 
consider a safe enough place (prior to any chroot)ing. 

=> Fair to assume key rollover is out of scope for this key (we could 
even do this empheral - and regenerate on renewal) ?

=> Fair to assume we just use one for all domains ?

-   Register this on first run. 

=>  Fair to assume things like contact email and EULA ok are out of 
scope ?

-   Build up a cert for each vhost; with all aliases added too as altnames. 

- for each vhost (altname) — get a challenge from the ACME server.

=>  Fair to assume we do not care about account recovery ?

-   bring up that/all vhost on their port 80  (all vhosts that have 
LetsEncrypt set to auto/on).

=> so if I understand the spec right - only port 80

==>  thus fair to assume non-root startup is out of 
scope - as we need to bind to a port < 1024.

So therefore:
=> fair to configure this ‘easier’ — i.e. if you do 
LetsEnrypt on on a domain SSL auto switches on and port 80 becomes an automatic 
redirect to https ?

-   Respond to the well know URI with each of he challenges.

-   Fetch/poll for the cert; save with 0600 and tight UID and be done.

-   Gracefully fail for each domain after N seconds - blocking https and 
with a sorry no ACME on http.

=>  do we need to allow for an ErrorDocument customisation of the 
latter ?

-   Set up a sane virtual SSL set of directives; and then chroot/suid/fork 
and start your normal run.

-   Switch of http or make http a blind to https forwarder.

-   Can we assume that the server has a graceful restart every week ? 

=> And thus declare ACME renewal from within out of scope  ?

Or do we need to auto disable SSL and go to http ?

Does that make sense - or have I oversimplified it and lost the plot ?

Dw

Re: mod_lets-encrypt

2017-01-14 Thread Rich Bowen 
I talked with him at linuxcon, but there's been no followup. I for one
would love to see this happen.

On Jan 10, 2017 12:15 PM, "Jacob Champion"  wrote:

> On 01/10/2017 08:35 AM, Dirk-Willem van Gulik wrote:
>
>> Before I send someone into the woods - did anyone consider/do a quick
>> ‘mod_lets_encrypt’ (with or without a persistent store) — that
>> requires virtually no configuration ?
>>
>
> Considered? Yes. Back in August there was some discussion on this list
> with Josh Aas. I don't know what the current status is.
>
> See
>
>
> https://lists.apache.org/thread.html/ea902ae8e453b3a8d363453
> 18fc74a54880d8bf14fed24e665c4b833@%3Cdev.httpd.apache.org%3E
>
> and
>
>
> https://lists.apache.org/thread.html/27d1fce7d30d9e31e247204
> 5c260e4f8dcefd300a731ff9e435a5d4a@%3Cdev.httpd.apache.org%3E
>
> --Jacob
>