Re: SSL and Usability and Safety

[Stefan Eissing]

> Am 03.05.2017 um 15:46 schrieb Issac Goldstand :
> 
> On 5/3/2017 4:28 PM, Stefan Eissing wrote:
>> 
>>> Am 03.05.2017 um 15:22 schrieb Dirk-Willem van Gulik :
>>> 
 
 On 3 May 2017, at 15:14, Issac Goldstand  wrote:
 
 On 5/3/2017 3:59 PM, Dirk-Willem van Gulik wrote:
> 
>> On 3 May 2017, at 14:53, Issac Goldstand > > wrote:
>> 
>> On 5/3/2017 12:46 PM, Dirk-Willem van Gulik wrote:
>>> On 3 May 2017, at 10:03, Issac Goldstand >> > wrote:
 
 +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
>>> ….
>>> 
>>> So how about ‘us’ taking the lead here. 
>> 
>> That's the part I was always +1 on :)
>> 
>>> We, here, simply define ‘one’ setting as the industry best standard -
>>> which roughly corresponds to what ssllabs their test would get you an
>>> A+ and that pretty much meets or exceeds the various NIST et.al.
>>> recommendations for key lengths for the next 5 years. 
>> 
>> The problem is, that we don't know what's going to be good going forward
>> five years, and IMHO the best standards are shaped at least equally by
>> removing "negatives" often because of high-risk vulnerabilities, as by
>> adding new "positives" due to new available ciphers/tools
> 
> Right - so I think there are two things
> 
> 1)the general advice of NIST et.al. - summarized nicely at:
> 
> https://www.keylength.com
> 
> which tells us what our `best acceptable’ choises are in any release
> going out and their likely vailidy for the next 5 years.
> 
> And then there is our response to things that become known; such as
> vulnerability - for which we have a proven update proces that is
> dovetailed by us sending mail to announce, the security mailing lists
> and similar outreach.
 
 Which, IMHO, we can safely expect Mr and Mrs Normal to never see.  Mr
 and Mrs normal aren't on the mailing list of most pieces of software,
 even if they use them.
 
 If we truly want to cater to them (and by doing so, do our part in
 advocating a safer and more secure internet) then I maintain that we'd
 need to do better.
>>> 
>>> Right - but then we are in the land of automatic updates; binary package 
>>> fetching and what not ? Or at the very least - pulling down a file over the 
>>> internet from ‘us’ that is sufficiently protected yet robust, etc ?
>>> 
>>> That is a whole new land?
>> 
>> I think there is a step in between. If we make our releases security 
>> settings better and users opt-in, we can with every release improve that. 
>> Nothing to change in the processes here.
>> 
>> In case our settings prove to have a fault, there is always the possibility 
>> for 
>> a) ship a new release
>> b) specify an immediate workaround by using the existing SSL* directives 
>> appropriately
> 
> But we already (potentially) do that with the maintained
> conf/extra/httpd-ssl.conf don't we?  How are all of the ideas we've been
> floating more than just sugar coating for the recommendations we already
> maintain there?

Maybe I have not explained well enough what I propose to add to the server.

a) add 2 new SSL directives: SSLSecurityPolicy and SSLPolicyOverride
b) make no change in behaviour/defaults when no SSLSecurityPolicy is configured
c) On a SSLSecurityPolicy, change the defaults for certain SSL* directives in 
alignment with the chosen policy. (On config merging, this will reset these 
directives effectively.)
d) On "SSLPolicyOverride deny", fail configurations where SSL* directives try 
to change what a policy defines (this applies also on config merging).

This brings the following benefits to the users:
1. It's easier to communicate your site has security policy "modern" than 
mentioning 9 directives (see 
https://mozilla.github.io/server-side-tls/ssl-config-generator/) where one 
directive is a line of 274 chars of gibberish (important one, but still)
2. It's easier to get right, and thus will provide a safer internet
3. We can adapt it in releases to reflect the current state of the art in TLS 
and browser (and our server) techology. Making the internet more secure.
4. In a setup with many config files, you can make certain that the policy 
applies and is not overwritten (if you so 

Re: SSL and Usability and Safety

[Issac Goldstand]

On 5/3/2017 4:28 PM, Stefan Eissing wrote:
> 
>> Am 03.05.2017 um 15:22 schrieb Dirk-Willem van Gulik :
>>
>>>
>>> On 3 May 2017, at 15:14, Issac Goldstand  wrote:
>>>
>>> On 5/3/2017 3:59 PM, Dirk-Willem van Gulik wrote:

> On 3 May 2017, at 14:53, Issac Goldstand  > wrote:
>
> On 5/3/2017 12:46 PM, Dirk-Willem van Gulik wrote:
>> On 3 May 2017, at 10:03, Issac Goldstand > > wrote:
>>>
>>> +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
>> ….
>>
>> So how about ‘us’ taking the lead here. 
>
> That's the part I was always +1 on :)
>
>> We, here, simply define ‘one’ setting as the industry best standard -
>> which roughly corresponds to what ssllabs their test would get you an
>> A+ and that pretty much meets or exceeds the various NIST et.al.
>> recommendations for key lengths for the next 5 years. 
>
> The problem is, that we don't know what's going to be good going forward
> five years, and IMHO the best standards are shaped at least equally by
> removing "negatives" often because of high-risk vulnerabilities, as by
> adding new "positives" due to new available ciphers/tools

 Right - so I think there are two things

 1)the general advice of NIST et.al. - summarized nicely at:

 https://www.keylength.com

 which tells us what our `best acceptable’ choises are in any release
 going out and their likely vailidy for the next 5 years.

 And then there is our response to things that become known; such as
 vulnerability - for which we have a proven update proces that is
 dovetailed by us sending mail to announce, the security mailing lists
 and similar outreach.
>>>
>>> Which, IMHO, we can safely expect Mr and Mrs Normal to never see.  Mr
>>> and Mrs normal aren't on the mailing list of most pieces of software,
>>> even if they use them.
>>>
>>> If we truly want to cater to them (and by doing so, do our part in
>>> advocating a safer and more secure internet) then I maintain that we'd
>>> need to do better.
>>
>> Right - but then we are in the land of automatic updates; binary package 
>> fetching and what not ? Or at the very least - pulling down a file over the 
>> internet from ‘us’ that is sufficiently protected yet robust, etc ?
>>
>> That is a whole new land?
> 
> I think there is a step in between. If we make our releases security settings 
> better and users opt-in, we can with every release improve that. Nothing to 
> change in the processes here.
> 
> In case our settings prove to have a fault, there is always the possibility 
> for 
> a) ship a new release
> b) specify an immediate workaround by using the existing SSL* directives 
> appropriately

But we already (potentially) do that with the maintained
conf/extra/httpd-ssl.conf don't we?  How are all of the ideas we've been
floating more than just sugar coating for the recommendations we already
maintain there?

> 
> -Stefan
> 

Re: SSL and Usability and Safety

[Issac Goldstand]

On 5/3/2017 4:22 PM, Dirk-Willem van Gulik wrote:
> 
>> On 3 May 2017, at 15:14, Issac Goldstand  wrote:
>>
>> On 5/3/2017 3:59 PM, Dirk-Willem van Gulik wrote:
>>>
 On 3 May 2017, at 14:53, Issac Goldstand > wrote:

 On 5/3/2017 12:46 PM, Dirk-Willem van Gulik wrote:
> On 3 May 2017, at 10:03, Issac Goldstand  > wrote:
>>
>> +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
> ….
>
> So how about ‘us’ taking the lead here. 

 That's the part I was always +1 on :)

> We, here, simply define ‘one’ setting as the industry best standard -
> which roughly corresponds to what ssllabs their test would get you an
> A+ and that pretty much meets or exceeds the various NIST et.al.
> recommendations for key lengths for the next 5 years. 

 The problem is, that we don't know what's going to be good going forward
 five years, and IMHO the best standards are shaped at least equally by
 removing "negatives" often because of high-risk vulnerabilities, as by
 adding new "positives" due to new available ciphers/tools
>>>
>>> Right - so I think there are two things
>>>
>>> 1)the general advice of NIST et.al. - summarized nicely at:
>>>
>>> https://www.keylength.com
>>>
>>> which tells us what our `best acceptable’ choises are in any release
>>> going out and their likely vailidy for the next 5 years.
>>>
>>> And then there is our response to things that become known; such as
>>> vulnerability - for which we have a proven update proces that is
>>> dovetailed by us sending mail to announce, the security mailing lists
>>> and similar outreach.
>>
>> Which, IMHO, we can safely expect Mr and Mrs Normal to never see.  Mr
>> and Mrs normal aren't on the mailing list of most pieces of software,
>> even if they use them.
>>
>> If we truly want to cater to them (and by doing so, do our part in
>> advocating a safer and more secure internet) then I maintain that we'd
>> need to do better.
> 
> Right - but then we are in the land of automatic updates; binary package 
> fetching and what not ? Or at the very least - pulling down a file over the 
> internet from ‘us’ that is sufficiently protected yet robust, etc ?
> 
> That is a whole new land?
> 
> Dw.
> 

Agreed, it is a whole new land. However, if we truly want a simple
"turnkey" method for MR and Mrs Normal, I don't see any other way that
will have fast-enough turnaround when vulnerabilities are discovered.

There's precedent for this sort of update mechanism inside the ASF with
SpamAssassin.  However, IMHO it doesn't make sense to reach out to them
to hear their thoughts of how sa-upadate deals with that land or
otherwise overthink this until we have some internal consensus that this
is an avenue that we would hypothetically be ok supporting.

If it's not turn-key, I don't see Mr and Mrs normal using it, and then
we could solve this for the rest of our users with a docs update.

The macros ideas are nifty, but I can't think of any use case where, for
example, a sysadmin (most definately NOT mr or mrs normal) would want to
configure multiple sets of macros on a single instance.

Re: SSL and Usability and Safety

[Stefan Eissing]

> Am 03.05.2017 um 15:22 schrieb Dirk-Willem van Gulik :
> 
>> 
>> On 3 May 2017, at 15:14, Issac Goldstand  wrote:
>> 
>> On 5/3/2017 3:59 PM, Dirk-Willem van Gulik wrote:
>>> 
 On 3 May 2017, at 14:53, Issac Goldstand > wrote:
 
 On 5/3/2017 12:46 PM, Dirk-Willem van Gulik wrote:
> On 3 May 2017, at 10:03, Issac Goldstand  > wrote:
>> 
>> +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
> ….
> 
> So how about ‘us’ taking the lead here. 
 
 That's the part I was always +1 on :)
 
> We, here, simply define ‘one’ setting as the industry best standard -
> which roughly corresponds to what ssllabs their test would get you an
> A+ and that pretty much meets or exceeds the various NIST et.al.
> recommendations for key lengths for the next 5 years. 
 
 The problem is, that we don't know what's going to be good going forward
 five years, and IMHO the best standards are shaped at least equally by
 removing "negatives" often because of high-risk vulnerabilities, as by
 adding new "positives" due to new available ciphers/tools
>>> 
>>> Right - so I think there are two things
>>> 
>>> 1)the general advice of NIST et.al. - summarized nicely at:
>>> 
>>> https://www.keylength.com
>>> 
>>> which tells us what our `best acceptable’ choises are in any release
>>> going out and their likely vailidy for the next 5 years.
>>> 
>>> And then there is our response to things that become known; such as
>>> vulnerability - for which we have a proven update proces that is
>>> dovetailed by us sending mail to announce, the security mailing lists
>>> and similar outreach.
>> 
>> Which, IMHO, we can safely expect Mr and Mrs Normal to never see.  Mr
>> and Mrs normal aren't on the mailing list of most pieces of software,
>> even if they use them.
>> 
>> If we truly want to cater to them (and by doing so, do our part in
>> advocating a safer and more secure internet) then I maintain that we'd
>> need to do better.
> 
> Right - but then we are in the land of automatic updates; binary package 
> fetching and what not ? Or at the very least - pulling down a file over the 
> internet from ‘us’ that is sufficiently protected yet robust, etc ?
> 
> That is a whole new land?

I think there is a step in between. If we make our releases security settings 
better and users opt-in, we can with every release improve that. Nothing to 
change in the processes here.

In case our settings prove to have a fault, there is always the possibility for 
a) ship a new release
b) specify an immediate workaround by using the existing SSL* directives 
appropriately

-Stefan

Re: SSL and Usability and Safety

[Dirk-Willem van Gulik]

> On 3 May 2017, at 15:14, Issac Goldstand  wrote:
> 
> On 5/3/2017 3:59 PM, Dirk-Willem van Gulik wrote:
>> 
>>> On 3 May 2017, at 14:53, Issac Goldstand >> > wrote:
>>> 
>>> On 5/3/2017 12:46 PM, Dirk-Willem van Gulik wrote:
 On 3 May 2017, at 10:03, Issac Goldstand > wrote:
> 
> +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
 ….
 
 So how about ‘us’ taking the lead here. 
>>> 
>>> That's the part I was always +1 on :)
>>> 
 We, here, simply define ‘one’ setting as the industry best standard -
 which roughly corresponds to what ssllabs their test would get you an
 A+ and that pretty much meets or exceeds the various NIST et.al.
 recommendations for key lengths for the next 5 years. 
>>> 
>>> The problem is, that we don't know what's going to be good going forward
>>> five years, and IMHO the best standards are shaped at least equally by
>>> removing "negatives" often because of high-risk vulnerabilities, as by
>>> adding new "positives" due to new available ciphers/tools
>> 
>> Right - so I think there are two things
>> 
>> 1)the general advice of NIST et.al. - summarized nicely at:
>> 
>> https://www.keylength.com
>> 
>> which tells us what our `best acceptable’ choises are in any release
>> going out and their likely vailidy for the next 5 years.
>> 
>> And then there is our response to things that become known; such as
>> vulnerability - for which we have a proven update proces that is
>> dovetailed by us sending mail to announce, the security mailing lists
>> and similar outreach.
> 
> Which, IMHO, we can safely expect Mr and Mrs Normal to never see.  Mr
> and Mrs normal aren't on the mailing list of most pieces of software,
> even if they use them.
> 
> If we truly want to cater to them (and by doing so, do our part in
> advocating a safer and more secure internet) then I maintain that we'd
> need to do better.

Right - but then we are in the land of automatic updates; binary package 
fetching and what not ? Or at the very least - pulling down a file over the 
internet from ‘us’ that is sufficiently protected yet robust, etc ?

That is a whole new land?

Dw.

Re: SSL and Usability and Safety

[Issac Goldstand]

On 5/3/2017 3:59 PM, Dirk-Willem van Gulik wrote:
> 
>> On 3 May 2017, at 14:53, Issac Goldstand > > wrote:
>>
>> On 5/3/2017 12:46 PM, Dirk-Willem van Gulik wrote:
>>> On 3 May 2017, at 10:03, Issac Goldstand >> > wrote:

 +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
>>> ….
>>>
>>> So how about ‘us’ taking the lead here. 
>>
>> That's the part I was always +1 on :)
>>
>>> We, here, simply define ‘one’ setting as the industry best standard -
>>> which roughly corresponds to what ssllabs their test would get you an
>>> A+ and that pretty much meets or exceeds the various NIST et.al.
>>> recommendations for key lengths for the next 5 years. 
>>
>> The problem is, that we don't know what's going to be good going forward
>> five years, and IMHO the best standards are shaped at least equally by
>> removing "negatives" often because of high-risk vulnerabilities, as by
>> adding new "positives" due to new available ciphers/tools
> 
> Right - so I think there are two things
> 
> 1)the general advice of NIST et.al. - summarized nicely at:
> 
> https://www.keylength.com
> 
> which tells us what our `best acceptable’ choises are in any release
> going out and their likely vailidy for the next 5 years.
> 
> And then there is our response to things that become known; such as
> vulnerability - for which we have a proven update proces that is
> dovetailed by us sending mail to announce, the security mailing lists
> and similar outreach.

Which, IMHO, we can safely expect Mr and Mrs Normal to never see.  Mr
and Mrs normal aren't on the mailing list of most pieces of software,
even if they use them.

If we truly want to cater to them (and by doing so, do our part in
advocating a safer and more secure internet) then I maintain that we'd
need to do better.

> 
>>> We’d wrap this into a simple policy document. Promise ourselfves that
>>> we’d check this every release and at least once a year review it. And
>>> have a small list of the versions currently meeting or exceeding our
>>> policy.
>>>
>>> And this is the setting you get when you do ‘SSLEngine On’.
>>
>> To me this doesn't address the time lags between shipping it in source,
>> and it getting implemented on the machine.  I don't see it as superior
>> in any way to, say, putting the recommended settings in the online docs
>> and updating that from time to time - moreso when that update is in
>> response to a new vulnerability.
> 
> I think we should make sure that 1) any release that goes out meets or
> exceeds industry practice (e.g. the BSI 2017 recommendation up to 2022);
> and 2) that we keep a list of versions that are still `current’ enough;
> and that accomodates what we since their release learned. Typically
> meaning - update to version X.Y.
> 
> Dw

Re: SSL and Usability and Safety

[Dirk-Willem van Gulik]

> On 3 May 2017, at 14:53, Issac Goldstand  wrote:
> 
> On 5/3/2017 12:46 PM, Dirk-Willem van Gulik wrote:
>> On 3 May 2017, at 10:03, Issac Goldstand  wrote:
>>> 
>>> +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
>> ….
>> 
>> So how about ‘us’ taking the lead here. 
> 
> That's the part I was always +1 on :)
> 
>> We, here, simply define ‘one’ setting as the industry best standard - which 
>> roughly corresponds to what ssllabs their test would get you an A+ and that 
>> pretty much meets or exceeds the various NIST et.al. recommendations for key 
>> lengths for the next 5 years. 
> 
> The problem is, that we don't know what's going to be good going forward
> five years, and IMHO the best standards are shaped at least equally by
> removing "negatives" often because of high-risk vulnerabilities, as by
> adding new "positives" due to new available ciphers/tools

Right - so I think there are two things

1)  the general advice of NIST et.al. - summarized nicely at:

https://www.keylength.com

which tells us what our `best acceptable’ choises are in any release going out 
and their likely vailidy for the next 5 years.

And then there is our response to things that become known; such as 
vulnerability - for which we have a proven update proces that is dovetailed by 
us sending mail to announce, the security mailing lists and similar outreach.

>> We’d wrap this into a simple policy document. Promise ourselfves that we’d 
>> check this every release and at least once a year review it. And have a 
>> small list of the versions currently meeting or exceeding our policy.
>> 
>> And this is the setting you get when you do ‘SSLEngine On’.
> 
> To me this doesn't address the time lags between shipping it in source,
> and it getting implemented on the machine.  I don't see it as superior
> in any way to, say, putting the recommended settings in the online docs
> and updating that from time to time - moreso when that update is in
> response to a new vulnerability.

I think we should make sure that 1) any release that goes out meets or exceeds 
industry practice (e.g. the BSI 2017 recommendation up to 2022); and 2) that we 
keep a list of versions that are still `current’ enough; and that accomodates 
what we since their release learned. Typically meaning - update to version X.Y.

Dw

Re: SSL and Usability and Safety

[Issac Goldstand]

On 5/3/2017 12:46 PM, Dirk-Willem van Gulik wrote:
> On 3 May 2017, at 10:03, Issac Goldstand  wrote:
>>
>> +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
>  ….
> 
> So how about ‘us’ taking the lead here. 

That's the part I was always +1 on :)

> 
> We, here, simply define ‘one’ setting as the industry best standard - which 
> roughly corresponds to what ssllabs their test would get you an A+ and that 
> pretty much meets or exceeds the various NIST et.al. recommendations for key 
> lengths for the next 5 years. 
> 

The problem is, that we don't know what's going to be good going forward
five years, and IMHO the best standards are shaped at least equally by
removing "negatives" often because of high-risk vulnerabilities, as by
adding new "positives" due to new available ciphers/tools

> We’d wrap this into a simple policy document. Promise ourselfves that we’d 
> check this every release and at least once a year review it. And have a small 
> list of the versions currently meeting or exceeding our policy.
> 
> And this is the setting you get when you do ‘SSLEngine On’.

To me this doesn't address the time lags between shipping it in source,
and it getting implemented on the machine.  I don't see it as superior
in any way to, say, putting the recommended settings in the online docs
and updating that from time to time - moreso when that update is in
response to a new vulnerability.

> 
> Everything else stays as is.
> 
> Dw
> 

Re: SSL and Usability and Safety

[Stefan Eissing]

I try to summarise the many replies (and thanks for the interest!), to sketch 
out a possible path forward.

1. Overall
--
Replies in general have been very positive.
 wr...@rowe-clan.net: "I like the proposal."
 rainer.j...@kippdata.de: "I like the idea."
 champio...@gmail.com: "+1 to this idea"

Some concerns were raised:

> Am 02.05.2017 um 22:42 schrieb Daniel :
> I am a bit concerned about the implications something like this may bring to 
> you guys, let me explain.
> [...after updating...]
>  it will fail, maybe the Mr. and Ms. Normal won't be able to figure out since 
> they changed nothing and the thing just started failing for them?

> Am 02.05.2017 um 23:10 schrieb Eric Covener :
> They upgraded. The few broken users will have a better chance of
> understanding what changed from CHANGES or the manual then most users
> have of understanding what "HIGH:!PSK:!aNULL:!EXP:!SRP" really
> "means".

Others have similar things. OpenSSL itself defines classes (not specifically 
targeted at HTTP. I once talked with Rich Salz about this and he said the 
OpenSSL is not aware of the application protocol. Layering.) and AWS has 
standard and user-defined policies. Something very similar. it seems.

Besides security policy, this could be used for other things:

> Am 02.05.2017 um 23:01 schrieb Helmut K. C. Tessarek :
> It would be great to explain the performance impact per setting.
> 

Whatever categories we define where etc. I think we can agree that
 a. Security policy needs to be an opt-in. No existing config will change 
unless the user choses a policy.
 b. One value of policy names is that they can be easier to understand (if 
there are not too many), if given a comprehensible name.
 
 Less clear:
 c. Another value of security policies is that their definition can be updated 
by the project. "modern" is not "modern" from 2005.
There is discussion needed about this aspect. Basically, do we want 
policies like
i. "modern" which we update, or
ii. "strong-2017" which we freeze

 The upside of i. is we can improve life for people who are not full time 
employed as apache admins. The downside of it is that we can break sites with a 
policy update.


2. Categories
-
 a. There is discussion if we should use the Mozilla Policy definions "modern", 
"intermediate" and "old". There is discussion if especially "old" is useful.

 b. There is discussion about the impact on config merging:

> Am 02.05.2017 um 19:28 schrieb Rainer Jung :
> a) in order of occurrence in the config files (order of reading)
> b) the most secure settings win
> c) first apply the "intent" directive, then merge the existing detail 
> settings on top

> I guess c) would be the most logical, but probably needs some additional 
> feature in config parsing.

> Am 02.05.2017 um 19:32 schrieb Ruediger Pluem :
> c) would be the best, but a) IMHO would be acceptable since overwriting is 
> for the more advanced users anyway and they
> can be told to do stuff in the correct order.

I think this merits its own thread.

3. Place of Definition
--
Code vs. Config Files vs. Macros vs. "Owned Macros"

> Am 03.05.2017 um 00:48 schrieb Jacob Champion :
> 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?

> Am 03.05.2017 um 03:11 schrieb Daniel Ruggeri :
> 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.

> Am 03.05.2017 um 09:37 schrieb Luca Toscano :
> One thing that I'd would really like to see as admin would be a quick way to 
> dump/inspect/visualize what SSLSecurityLevel 2017-05 corresponds to 
> (SSLDirectiveX set to foo, SSLDirectiveY set to bar, etc..). Even better 
> would be to have also a little bit of description attached to the dump, or 
> just a reference to the docs.

I think this also merits its own thread.

4. Update Process
-
Some people talk about the need for new processes here.
> Am 03.05.2017 um 10:03 schrieb Issac Goldstand :
> 
> 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 

Re: SSL and Usability and Safety

[Dirk-Willem van Gulik]

On 3 May 2017, at 10:03, Issac Goldstand  wrote:
> 
> +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
 ….

So how about ‘us’ taking the lead here. 

We, here, simply define ‘one’ setting as the industry best standard - which 
roughly corresponds to what ssllabs their test would get you an A+ and that 
pretty much meets or exceeds the various NIST et.al. recommendations for key 
lengths for the next 5 years. 

We’d wrap this into a simple policy document. Promise ourselfves that we’d 
check this every release and at least once a year review it. And have a small 
list of the versions currently meeting or exceeding our policy.

And this is the setting you get when you do ‘SSLEngine On’.

Everything else stays as is.

Dw

Re: SSL and Usability and Safety

[Ben Laurie]

On 3 May 2017 at 09:03, Issac Goldstand  wrote:
> 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.

FWIW, this seems like the right approach to me.

Re: SSL and Usability and Safety

[Issac Goldstand]

+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 <champio...@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
> 

Re: SSL and Usability and Safety

[Luca Toscano]

2017-05-03 2:29 GMT+02:00 Graham Leggett :

> On 02 May 2017, at 3:19 PM, Stefan Eissing 
> wrote:
>
> How can we help Mr and Ms Normal to stay up to date on these things?
>
> - We cannot rewrite their config unasked. We need to be backward
> compatible.
> - Our defaults nowadays are dangerously unsafe, so users MUST do their own
> settings.
>
> I advocate that we need (yet another!) SSL directive where administrators
> can declare their *intent*.
>
> A. "I want my site safe and usable with modern browsers!"
> B. "I want a safe setting, but people with slightly out-dated clients
> should be served as well."
> C. "I sadly need compatibility to some very old clients.”
>
>
> This makes a lot of sense, and there is a lot of precedent for this.
>
> AWS load balancers take an “intent” policy string based on a date, with
> the option of a “default” value:
>
> http://docs.aws.amazon.com/elasticloadbalancing/latest/
> classic/ssl-config-update.html
>
> --
> |  DescribeLoadBalancerPolicies  |
> ++
> |   PolicyName   |
> ++
> |  ELBSecurityPolicy-2016-08 |
> |  ELBSecurityPolicy-2015-05 |
> |  ELBSecurityPolicy-2015-03 |
> |  ELBSecurityPolicy-2015-02 |
> |  ELBSecurityPolicy-2014-10 |
> |  ELBSecurityPolicy-2014-01 |
> |  ELBSecurityPolicy-2011-08 |
> |  ELBSample-ELBDefaultCipherPolicy  |
> |  ELBSample-OpenSSLDefaultCipherPolicy  |
> ++
>
> Implementation wise, we could have a directive that is used to select the
> default values of various parameters, for example:
>
> SSLSecurityLevel latest
>
> or
>
> SSLSecurityLevel 2017-05
>

Really like this idea, it seems a good compromise to me. While reading the
email thread I was worried about keeping separate configuration and
implementation, but this approach makes me feel better.

One thing that I'd would really like to see as admin would be a quick way
to dump/inspect/visualize what SSLSecurityLevel 2017-05 corresponds to
(SSLDirectiveX set to foo, SSLDirectiveY set to bar, etc..). Even better
would be to have also a little bit of description attached to the dump, or
just a reference to the docs.

Luca

Re: SSL and Usability and Safety

[Daniel Ruggeri]

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


 Original Message 
From: Jacob Champion <champio...@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

Re: SSL and Usability and Safety

[Eric Covener]

On Tue, May 2, 2017 at 8:29 PM, Graham Leggett  wrote:
>
> This makes a lot of sense, and there is a lot of precedent for this.
>
> AWS load balancers take an “intent” policy string based on a date, with the
> option of a “default” value:
>
> http://docs.aws.amazon.com/elasticloadbalancing/latest/classic/ssl-config-update.html
>
> --
> |  DescribeLoadBalancerPolicies  |
> ++
> |   PolicyName   |
> ++


Neat approach, I hadn't seen that.

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

Re: SSL and Usability and Safety

[Graham Leggett]

On 02 May 2017, at 3:19 PM, Stefan Eissing  wrote:

> How can we help Mr and Ms Normal to stay up to date on these things?
> 
> - We cannot rewrite their config unasked. We need to be backward compatible.
> - Our defaults nowadays are dangerously unsafe, so users MUST do their own 
> settings.
> 
> I advocate that we need (yet another!) SSL directive where administrators can 
> declare their *intent*.
> 
> A. "I want my site safe and usable with modern browsers!"
> B. "I want a safe setting, but people with slightly out-dated clients should 
> be served as well."
> C. "I sadly need compatibility to some very old clients.”

This makes a lot of sense, and there is a lot of precedent for this.

AWS load balancers take an “intent” policy string based on a date, with the 
option of a “default” value:

http://docs.aws.amazon.com/elasticloadbalancing/latest/classic/ssl-config-update.html
--
|  DescribeLoadBalancerPolicies  |
++
|   PolicyName   |
++
|  ELBSecurityPolicy-2016-08 |
|  ELBSecurityPolicy-2015-05 |
|  ELBSecurityPolicy-2015-03 |
|  ELBSecurityPolicy-2015-02 |
|  ELBSecurityPolicy-2014-10 |
|  ELBSecurityPolicy-2014-01 |
|  ELBSecurityPolicy-2011-08 |
|  ELBSample-ELBDefaultCipherPolicy  |
|  ELBSample-OpenSSLDefaultCipherPolicy  |
++
Implementation wise, we could have a directive that is used to select the 
default values of various parameters, for example:

SSLSecurityLevel latest

or

SSLSecurityLevel 2017-05

Regards,
Graham
—



smime.p7s
Description: S/MIME cryptographic signature

Re: SSL and Usability and Safety

[Jacob Champion]

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

Re: SSL and Usability and Safety

[Jacob Champion]

On 05/02/2017 02:01 PM, Helmut K. C. Tessarek wrote:

I'm not sure, how much perf difference there is between A, B, and C, but
SSL by itself has quite an impact


(For the record, our bucket brigade implementation is currently 
hamstringing our TLS static file performance, and on top of that OpenSSL 
is doing an awful lot of memcpy's that might(?) not be necessary, so we 
have to be careful when declaring "TLS has an impact" vs "our 
implementation has an impact when TLS is enabled".)


But otherwise agreed: relative performance would be another great thing 
to document for these settings.


--Jacob

Re: SSL and Usability and Safety

[Eric Covener]

On Tue, May 2, 2017 at 4:42 PM, Daniel  wrote:
> ould these changes/choices be permanent after different releases of httpd?
> If not, what if httpd "choices" settings as commented  at the beginning of
> this thread screw the need for a very important client with java 1.crap
> which can handle DH just fine but after accepting the ciphert if the private
> key is bigger than  it will fail, maybe the Mr. and Ms. Normal won't be
> able to figure out since they changed nothing and the thing just started
> failing for them?

They upgraded. The few broken users will have a better chance of
understanding what changed from CHANGES or the manual then most users
have of understanding what "HIGH:!PSK:!aNULL:!EXP:!SRP" really
"means".

I think to be useful, reasonable SSL defaults have to be subject to
change in maintenance (and over-rideable)

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

Re: SSL and Usability and Safety

[Helmut K. C. Tessarek]

On 2017-05-02 09:19, Stefan Eissing wrote:
> A. "I want my site safe and usable with modern browsers!"
> B. "I want a safe setting, but people with slightly out-dated clients should 
> be served as well."
> C. "I sadly need compatibility to some very old clients."

It would be great to explain the performance impact per setting.

The average Joe has no idea how to run benchmarks and interpret the
results. Yet I came across people who used the default settings
wondering why it wasn't performing that well.

I know, an average Joe shouldn't configure a web server (especially for
performance) in the first place, but you wouldn't believe how many
companies do not have proper resources.

I often heard people complaining that Apache wasn't performing well,
which in my opinion was misconfiguration and/or bad default settings.

Apache httpd deserves better than the younger generation favouring nginx
over Apache because of alleged better out of the box performance.

I'm not sure, how much perf difference there is between A, B, and C, but
SSL by itself has quite an impact, especially on boxes without the AES
CPU extension.

Cheers,
  K. C.

-- 
regards Helmut K. C. Tessarek
lookup http://pool.sks-keyservers.net for KeyID 0xC11F128D

/*
   Thou shalt not follow the NULL pointer for chaos and madness
   await thee at its end.
*/

Re: SSL and Usability and Safety

[Daniel]

Hello,

Sorry for the intrusion since I'm no dev.

I am a bit concerned about the implications something like this may bring
to you guys, let me explain.

Openssl aliases were made for something like that (HIGH MEDIUM LOW).
Although we all may agree Aliases are not great, with a little tweaking
someone can get a reasonable secure and compatible ciphersuite settings for
the time being, like HIGH:!PSK:!aNULL:!EXP:!SRP or similar.

The difference between slightly out-dated clients and very old clients can
yield lots of options as the cipher business is something very "granular"
(can't explain it better) and at the end of the day it is the admin of the
site the person who knows/should know which clients it is handling or wants
to handle and the security they need.

After all, Mr. and Ms. Normal are not very normal if they leave their SSL
settings without review for long periods of time.

Would these changes/choices be permanent after different releases of httpd?
If not, what if httpd "choices" settings as commented  at the beginning of
this thread screw the need for a very important client with java 1.crap
which can handle DH just fine but after accepting the ciphert if the
private key is bigger than  it will fail, maybe the Mr. and Ms. Normal
won't be able to figure out since they changed nothing and the thing just
started failing for them?

Maybe stepping on the "site admin's" business in favour of making it easier
for them with new settings can be opening a can of worms, since even if we
may document it quite well, well, we know "Mr. and Ms. Normal" may skeep
reading about that and forget about the implications.

Hope I didn't bring in too much noise.

Regards

-- 
*Daniel Ferradal*

Re: SSL and Usability and Safety

[Jacob Champion]

On 05/02/2017 11:48 AM, William A Rowe Jr wrote:

Are you referring to mod_ssl or a number of modules? If we find such
things, 2.next is our chance to correct any and all unexpected merge
behaviors.


A number of them, but it's less "there are bugs" and more "every 
directive/module does its own thing".


Are directives merged in file order? least-to-most-specific container 
order? breadth-first order across all containers (e.g. the new nested 
)? When conflicting directives are found, are they merged in some 
way, or is one just silently dropped? Stuff like that.


It's mostly off-topic for this thread, but if there's interest in a 
broader discussion, I can start one.


--Jacob

Re: SSL and Usability and Safety

[William A Rowe Jr]

On May 2, 2017 12:57 PM, "Jacob Champion"  wrote:

On 05/02/2017 10:32 AM, Ruediger Pluem wrote:

> c) would be the best, but a) IMHO would be acceptable since overwriting is
> for the more advanced users anyway and they
> can be told to do stuff in the correct order.
>

+1 to both points.

(Our conflict-merging logic in the configuration is not very consistent
across directives at the moment, so maybe this would be a good excuse to
have some conversations about that too?)


Are you referring to mod_ssl or a number of modules? If we find such
things, 2.next is our chance to correct any and all unexpected merge
behaviors.

Re: SSL and Usability and Safety

[Jacob Champion]

On 05/02/2017 10:32 AM, Ruediger Pluem wrote:

c) would be the best, but a) IMHO would be acceptable since overwriting is for 
the more advanced users anyway and they
can be told to do stuff in the correct order.


+1 to both points.

(Our conflict-merging logic in the configuration is not very consistent 
across directives at the moment, so maybe this would be a good excuse to 
have some conversations about that too?)


--Jacob

Re: SSL and Usability and Safety

[Jacob Champion]

On 05/02/2017 06:19 AM, Stefan Eissing wrote:

I advocate that we need (yet another!) SSL directive where administrators can 
declare their *intent*.

A. "I want my site safe and usable with modern browsers!"
B. "I want a safe setting, but people with slightly out-dated clients should be 
served as well."
C. "I sadly need compatibility to some very old clients."


+1 to this idea (including option C), and


PS. Yes, I would use Mozilla's modern/intermediate/old definitions, but that 
discussion would be the next step.


+1 to following the same pattern as Mozilla's compatibility classes. :)

--Jacob

Re: SSL and Usability and Safety

[Ruediger Pluem]

On 05/02/2017 07:28 PM, Rainer Jung wrote:
> Am 02.05.2017 um 15:19 schrieb Stefan Eissing:

> 
> Since we then have possibly conflicting config settings (your new "intent" 
> config directive and existing detailed config
> directives) we need to make sure, how merging (conflict resolution) is done 
> (even within the global server or one vhost):
> 
> a) in order of occurrence in the config files (order of reading)
> 
> b) the most secure settings win
> 
> c) first apply the "intent" directive, then merge the existing detail 
> settings on top
> 
> I guess c) would be the most logical, but probably needs some additional 
> feature in config parsing.

c) would be the best, but a) IMHO would be acceptable since overwriting is for 
the more advanced users anyway and they
can be told to do stuff in the correct order.

Regards

Rüdiger

Re: SSL and Usability and Safety

[Rainer Jung]

Am 02.05.2017 um 15:19 schrieb Stefan Eissing:

With 71 configuration directives, mod_ssl can manage probably every user's 
needs, but two: Mr and Ms Normal.

Ms and Mr Normal have a basic understanding about SSL, sorry TLS, and what a 
cipher is, but HonorCipherOrder is already a bit much and on OCSP stapling, the 
mind becomes a little bit hazy. They are smart and well educated in their field 
of work, they just do have not the time to read up on these things.

But they have heard about internet security and want people visiting their site 
to be safe (which is always relative).

What they do now is take Apache, google a bit around, find something on 
stackoverflow or maybe even the Mozilla config generator 
(https://mozilla.github.io/server-side-tls/ssl-config-generator/) and copy and 
paste what they find into their config file.

And then they never touch the config for the next couple of years. They will 
get updates and security fixes from the Linux distribution, but as long as the 
server runs, they will not investigate into a better SSL setting any more.

But everyone working in internet security know that these settings are (and 
maybe forever will be) in flux. Ciphers fall out of grace, new protocol 
versions rise and features like OCSP and HSTS get invented.

How can we help Mr and Ms Normal to stay up to date on these things?

- We cannot rewrite their config unasked. We need to be backward compatible.
- Our defaults nowadays are dangerously unsafe, so users MUST do their own 
settings.

I advocate that we need (yet another!) SSL directive where administrators can 
declare their *intent*.

A. "I want my site safe and usable with modern browsers!"
B. "I want a safe setting, but people with slightly out-dated clients should be 
served as well."
C. "I sadly need compatibility to some very old clients."

and Apache would figure out what these intentions mean for protocols, ciphers, 
ordering, ocsp and other settings. We ship updates with every release when they 
make sense to us. We could even ship a CVE Fix downstream that removes a 
certain cipher and it would apply to all sites using this new setting.

Does this make sense? I personally would use this on my sites...

Cheers,

Stefan

PS. Yes, I would use Mozilla's modern/intermediate/old definitions, but that 
discussion would be the next step.


I like the idea. I reminds me of OpenSSL security levels

https://www.openssl.org/docs/man1.1.0/ssl/SSL_CTX_get_security_level.html

although there is no 1:1 map, more a similarity of principles.

We have to see, how easy we get consensus on the "intent" names and 
actual settings associated to those.


Since we then have possibly conflicting config settings (your new 
"intent" config directive and existing detailed config directives) we 
need to make sure, how merging (conflict resolution) is done (even 
within the global server or one vhost):


a) in order of occurrence in the config files (order of reading)

b) the most secure settings win

c) first apply the "intent" directive, then merge the existing detail 
settings on top


I guess c) would be the most logical, but probably needs some additional 
feature in config parsing.


Regards,

Rainer

Re: SSL and Usability and Safety

[William A Rowe Jr]

On Tue, May 2, 2017 at 11:14 AM, William A Rowe Jr  wrote:
>
> Any other client is no longer interoperable with any popular site, following
> final changes by issues in Dec '16.

by *certificate issuers*.

E.g. all MD5 and SHA1 hashed certs are now expired, there is no longer a
need to support wildly ancient clients anymore.

> On May 2, 2017 8:19 AM, "Stefan Eissing" 
> wrote:
>>
>> C. "I sadly need compatibility to some very old clients."

Re: SSL and Usability and Safety

[William A Rowe Jr]

I like the proposal. However I see no need for the 'C' categor,
y and disagree about changing defaults during any future 2.next bump.

HonorCipherOrder, as an example, must be inverted.

Users requiring 'C' can override things to make that happen.

I see two 'quick start' one-line configs, strictly modern and cpu
intensive, or equally modern and just a bit more relaxed about cipher
strength.

Any other client is no longer interoperable with any popular site,
following final changes by issues in Dec '16.



On May 2, 2017 8:19 AM, "Stefan Eissing" 
wrote:

> With 71 configuration directives, mod_ssl can manage probably every user's
> needs, but two: Mr and Ms Normal.
>
> Ms and Mr Normal have a basic understanding about SSL, sorry TLS, and what
> a cipher is, but HonorCipherOrder is already a bit much and on OCSP
> stapling, the mind becomes a little bit hazy. They are smart and well
> educated in their field of work, they just do have not the time to read up
> on these things.
>
> But they have heard about internet security and want people visiting their
> site to be safe (which is always relative).
>
> What they do now is take Apache, google a bit around, find something on
> stackoverflow or maybe even the Mozilla config generator (
> https://mozilla.github.io/server-side-tls/ssl-config-generator/) and copy
> and paste what they find into their config file.
>
> And then they never touch the config for the next couple of years. They
> will get updates and security fixes from the Linux distribution, but as
> long as the server runs, they will not investigate into a better SSL
> setting any more.
>
> But everyone working in internet security know that these settings are
> (and maybe forever will be) in flux. Ciphers fall out of grace, new
> protocol versions rise and features like OCSP and HSTS get invented.
>
> How can we help Mr and Ms Normal to stay up to date on these things?
>
> - We cannot rewrite their config unasked. We need to be backward
> compatible.
> - Our defaults nowadays are dangerously unsafe, so users MUST do their own
> settings.
>
> I advocate that we need (yet another!) SSL directive where administrators
> can declare their *intent*.
>
> A. "I want my site safe and usable with modern browsers!"
> B. "I want a safe setting, but people with slightly out-dated clients
> should be served as well."
> C. "I sadly need compatibility to some very old clients."
>
> and Apache would figure out what these intentions mean for protocols,
> ciphers, ordering, ocsp and other settings. We ship updates with every
> release when they make sense to us. We could even ship a CVE Fix downstream
> that removes a certain cipher and it would apply to all sites using this
> new setting.
>
> Does this make sense? I personally would use this on my sites...
>
> Cheers,
>
> Stefan
>
> PS. Yes, I would use Mozilla's modern/intermediate/old definitions, but
> that discussion would be the next step.
>
>
>
>
>

SSL and Usability and Safety

[Stefan Eissing]

With 71 configuration directives, mod_ssl can manage probably every user's 
needs, but two: Mr and Ms Normal.

Ms and Mr Normal have a basic understanding about SSL, sorry TLS, and what a 
cipher is, but HonorCipherOrder is already a bit much and on OCSP stapling, the 
mind becomes a little bit hazy. They are smart and well educated in their field 
of work, they just do have not the time to read up on these things. 

But they have heard about internet security and want people visiting their site 
to be safe (which is always relative).

What they do now is take Apache, google a bit around, find something on 
stackoverflow or maybe even the Mozilla config generator 
(https://mozilla.github.io/server-side-tls/ssl-config-generator/) and copy and 
paste what they find into their config file.

And then they never touch the config for the next couple of years. They will 
get updates and security fixes from the Linux distribution, but as long as the 
server runs, they will not investigate into a better SSL setting any more.

But everyone working in internet security know that these settings are (and 
maybe forever will be) in flux. Ciphers fall out of grace, new protocol 
versions rise and features like OCSP and HSTS get invented.

How can we help Mr and Ms Normal to stay up to date on these things?

- We cannot rewrite their config unasked. We need to be backward compatible.
- Our defaults nowadays are dangerously unsafe, so users MUST do their own 
settings.

I advocate that we need (yet another!) SSL directive where administrators can 
declare their *intent*.

A. "I want my site safe and usable with modern browsers!"
B. "I want a safe setting, but people with slightly out-dated clients should be 
served as well."
C. "I sadly need compatibility to some very old clients."

and Apache would figure out what these intentions mean for protocols, ciphers, 
ordering, ocsp and other settings. We ship updates with every release when they 
make sense to us. We could even ship a CVE Fix downstream that removes a 
certain cipher and it would apply to all sites using this new setting.

Does this make sense? I personally would use this on my sites...

Cheers,

Stefan

PS. Yes, I would use Mozilla's modern/intermediate/old definitions, but that 
discussion would be the next step.