Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
Subject: Re: SSL and Usability and Safety
To: dev@httpd.apache.org
References: <C89196B3-2171-4D7C-BEB4-31E758763D41@greenbytes.de>
 <CAHti5NHWpFYi7p+gLbRvB23inmakLtZNa01GyFLrf5BpbqXVdw@mail.gmail.com>
 <CALK=YjNqyU2Uo0mKKrH9BqNYABkkAHSHKODU6Qnsha0_iufX3A@mail.gmail.com>
 <d37ec8b4-1575-ca04-2290-f3cda33460a3@gmail.com>
 <B0D7E477-DF31-48D5-AC9D-03285F202834@primary.net>
From: Issac Goldstand <margol@beamartyr.net>
Message-ID: <6801e32f-0cbb-8c6e-f902-57f6a49698ba@beamartyr.net>
Date: Wed, 3 May 2017 11:03:38 +0300
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101
 Thunderbird/45.7.1
MIME-Version: 1.0
In-Reply-To: <B0D7E477-DF31-48D5-AC9D-03285F202834@primary.net>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
archived-at: Wed, 03 May 2017 08:03:55 -0000

+1 on the idea

So far I'm -0 about all of the proposed implementations for 2 reasons:

1) Mr and Mrs normal (whom are our primary customers in the original
proposal) usually download Apache from their distro or some other
binary.  Their Apache sources are usually not up-to-date, and in the
scenario that a new vulnerability is found it would take ages to
propagate to them, anyway

2) For those users who are comfortable building their own source, they
run into our PMCs release timing.  What happens if a vulnerability is
released, we quickly backport from trunk[1] to whatever branches are
needed based on what's up-to-date and we want to release said old
branches?  Suddenly, we realize that one (or more) of these old branches
have changes unrelated to the vulnerability and we erupt into days or
weeks of constructive arguments on the merit of these other changes to
be released?

What would work, in my eyes, if people are open to it, is treating the
contents of these definitions/macros (and I'm all for the macros, just
so that interested sysadmins can see *exactly* what the settings are on
their setup) as apart from the httpd sources, and thus not subject to
the normal release cycle.  To clarify,  I mean the httpd tarball release
cycles specifically, not our policies for how we perform and vote on the
releases (although we'd need to come to agreement on how to allow for
quick releases in the face of security issues, so a 3 day vote followed
by release may not work).  Instead, we could do something similar to the
spamassassin project does with their base rules, where we have external
tooling (or internal tooling, if it's preferred) fetch the up-to-date
definitions from an ASF mirror server on a regular basis and override
the local definitions.

Best,
  Issac

[1] and this assumes we'd be keeping these configs in trunk, which is
kinda backwards IMHO,  given that trunk by definition is stuff with
potential to release at some point in the future, whereas these configs
are our published best-practice for *now*

On 5/3/2017 4:11 AM, Daniel Ruggeri wrote:
> I actually was going to respond in a similar way by proposing the use of
> files that could be Included. I really like this idea for all the
> reasons mentioned - the biggest being that it's trivial for a SecAdmin
> or WebAdmin to see what is in the Included file and its macros and what
> gets applied. I am also in support of regularly evolving the values
> because an admin making use of them is aware that they are delegating
> responsibility to us or their package vendor. The downside (which may no
> longer be valid - haven't looked in ages) is that I think Includes and
> Macros confuse line numbers in error messages.
> -- 
> Daniel Ruggeri
> 
> ------------------------------------------------------------------------
> *From:* Jacob Champion <champion.p@gmail.com>
> *Sent:* May 2, 2017 5:48:34 PM CDT
> *To:* dev@httpd.apache.org
> *Subject:* Re: SSL and Usability and Safety
> 
> On 05/02/2017 02:10 PM, Eric Covener wrote:
> 
>     I think to be useful, reasonable SSL defaults have to be subject to
>     change in maintenance (and over-rideable)
> 
> 
> So... this got me thinking. If we put this new "stuff" (whatever it 
> turns out to be) into a new directive,
> 
> - part of its operation gets tied to source code that's hidden from the 
> end user
> - we'll probably have to duplicate some SSL directive logic in the module
> - we have to figure out the merge/conflict scenarios, which -- while 
> definitely worthwhile in the long term -- feels likely to add complexity 
> to the short-term discussion
> 
> If all of the settings that are part of this new directive can be 
> described in terms of other already-existing directives, could we 
> implement it as a server-owned Macro?
> 
> - their implementation is public and auditable by anyone who understands 
> the config syntax
> - they can be easily patched for vulnerabilities without recompiling 
> anything
> - merge/conflict resolution will follow the individual directives' 
> current merge logic (whatever that happens to be)
> 
> We could reserve a macro prefix (or symbol) for the server and its 
> modules so that we don't step on anyone with future expansion. Then it's 
> just a matter of
> 
>      Include macros/ssl.conf
> 
>      Use !SslIntermediateSecuritySettings
> 
> We'd have to be very explicit that the macro definitions belong to the 
> server distribution, and installing a newer (or older) version of the 
> server would overwrite whatever changes you'd made to those macro files.
> 
> Thoughts?
> 
> --Jacob
>