Re: svn commit: r1824465 - /httpd/httpd/patches/2.4.x/mod_ssl_policy.diff

[Stefan Eissing]

> Am 19.02.2018 um 10:54 schrieb Yann Ylavic :
> 
> On Mon, Feb 19, 2018 at 10:42 AM, Stefan Eissing
>  wrote:
>> After pondering your comments and questions a bit over the weekend, I 
>> decided to
>> withdraw the backport proposal for 2.4.x. Instead, I will simplify SSLPolicy 
>> in
>> trunk and propose a backport for the next release.
>> 
>> My current thinking is to get rid of "" and just introduce
>> a fixed "SSLPolicy modern|intermediate|old" which is updated from the Mozilla
>> definitions of these terms (a script for that is already in modules/ssl). 
>> This
>> will only apply to the client facing SSL properties.
>> 
>> "SSLPolicy" will then just act as a normal SSL configuration directive, that
>> sets a defined number of parameters. Those parameters will get updated in our
>> releases (and by distros if they want to update a LTS version with a more 
>> secure
>> setting).
>> 
>> If can be overridden by site admins, just like any other directive. The 
>> configuration
>> 
>>   SSLProtocol all
>>   SSLPolicy modern
>> 
>> would just enable TLSv1.2 (and newer), while
>> 
>>   SSLPolicy modern
>>   SSLProtocol +TLSv1.3
>> 
>> would override it.
> 
> Looks good to me.
> 
> The all in one defined policy is interesting still, let's take the
> time to think more about it.
> It could possibly be implemented as macros too, no?

*Anything* can be implemented as a macro... ;-)

SSLPolicy does *not* mean: "compression off, protocols x y z, ciphers 
blabla-256"
SSLPolicy means: "what your Apache provider considers best SSL settings for 
modern browsers"

If you build from source from httpd.apache.org, it is what Mozilla considers 
modern
at the time of our release. If you get it from a distro, it means what they 
think relevant.
They could update it in years to come for an Apache in their LTS line.

By doing it as a new directive, we enable good advice:

"If you have an Apache > 2.4.30, use the following to configure your https: 
site."

Instead of:

"If you have an Apache > 2.4.30 with the standard macro definitions included 
and mod_macro
enabled, use the following... Btw. do not edit the macro definitions or your 
settings will
no longer auto-update. But if you do, check after every update also, if the 
macros are still
as you want them, because your changes may also have been overwritten."

The macro approach will not work for an internet that will be 99% https: very, 
very soon, IMO.

Cheers, Stefan

Re: svn commit: r1824465 - /httpd/httpd/patches/2.4.x/mod_ssl_policy.diff

[Yann Ylavic]

On Mon, Feb 19, 2018 at 10:42 AM, Stefan Eissing
 wrote:
> After pondering your comments and questions a bit over the weekend, I decided 
> to
> withdraw the backport proposal for 2.4.x. Instead, I will simplify SSLPolicy 
> in
> trunk and propose a backport for the next release.
>
> My current thinking is to get rid of "" and just introduce
> a fixed "SSLPolicy modern|intermediate|old" which is updated from the Mozilla
> definitions of these terms (a script for that is already in modules/ssl). This
> will only apply to the client facing SSL properties.
>
> "SSLPolicy" will then just act as a normal SSL configuration directive, that
> sets a defined number of parameters. Those parameters will get updated in our
> releases (and by distros if they want to update a LTS version with a more 
> secure
> setting).
>
> If can be overridden by site admins, just like any other directive. The 
> configuration
>
>SSLProtocol all
>SSLPolicy modern
>
> would just enable TLSv1.2 (and newer), while
>
>SSLPolicy modern
>SSLProtocol +TLSv1.3
>
> would override it.

Looks good to me.

The all in one defined policy is interesting still, let's take the
time to think more about it.
It could possibly be implemented as macros too, no?

Thanks,
Yann.

Re: svn commit: r1824465 - /httpd/httpd/patches/2.4.x/mod_ssl_policy.diff

[Stefan Eissing]

After pondering your comments and questions a bit over the weekend, I decided to
withdraw the backport proposal for 2.4.x. Instead, I will simplify SSLPolicy in
trunk and propose a backport for the next release.

My current thinking is to get rid of "" and just introduce
a fixed "SSLPolicy modern|intermediate|old" which is updated from the Mozilla
definitions of these terms (a script for that is already in modules/ssl). This 
will only apply to the client facing SSL properties.

"SSLPolicy" will then just act as a normal SSL configuration directive, that
sets a defined number of parameters. Those parameters will get updated in our
releases (and by distros if they want to update a LTS version with a more secure
setting). 

If can be overridden by site admins, just like any other directive. The 
configuration

   SSLProtocol all
   SSLPolicy modern

would just enable TLSv1.2 (and newer), while

   SSLPolicy modern
   SSLProtocol +TLSv1.3

would override it.

Cheers,

Stefan


> Am 17.02.2018 um 18:20 schrieb Stefan Eissing :
> 
>> 
>> Am 16.02.2018 um 17:34 schrieb Yann Ylavic :
>> 
>> Hi Stefan,
>> 
>> On Fri, Feb 16, 2018 at 2:05 PM,   wrote:
>>> Author: icing
>>> Date: Fri Feb 16 13:05:27 2018
>>> New Revision: 1824465
>>> 
>>> URL: http://svn.apache.org/viewvc?rev=1824465=rev
>>> Log:
>>> sslpolicy patch for 2.4.x
>> 
>> Quick incomplete/review, two question...
> 
> Thanks for reviewing.
> 
>> There seems to be predefined/moz policies with "SSLProxyVerify
>> require" enforced, how can it work w/o a CA? That impose also setting
>> SSLProxyCACertificate* for httpd to start/work, right?
> 
> If it only works with an explicit CA file, then it should not be
> on. I think I was hoping that openssl tied into some CA vault on
> its own and a CA file was only necessary for non-public certs.
> 
>>  is global only, but since it's not a real
>> directory/section itself anything can nest inside (including another
>> )?
> 
> Any non-SSL directive inside would not be part of it. That could
> lead to confusion, since other directives will not see the difference
> and will not complain. I am not sure if introducing new section types,
> which adds complexity in the server is worth it. We could add a section
> to the documentation that states this limitation more clearly.
> 
> Also, nesting  should be prevented, as it will
> not give the results that one would expect (I have not tested that,
> but I think it would behave as if the two were side by side).
> 
> Cheers,
> 
> Stefan

Re: svn commit: r1824465 - /httpd/httpd/patches/2.4.x/mod_ssl_policy.diff

[Stefan Eissing]

> Am 16.02.2018 um 17:34 schrieb Yann Ylavic :
> 
> Hi Stefan,
> 
> On Fri, Feb 16, 2018 at 2:05 PM,   wrote:
>> Author: icing
>> Date: Fri Feb 16 13:05:27 2018
>> New Revision: 1824465
>> 
>> URL: http://svn.apache.org/viewvc?rev=1824465=rev
>> Log:
>> sslpolicy patch for 2.4.x
> 
> Quick incomplete/review, two question...

Thanks for reviewing.

> There seems to be predefined/moz policies with "SSLProxyVerify
> require" enforced, how can it work w/o a CA? That impose also setting
> SSLProxyCACertificate* for httpd to start/work, right?

If it only works with an explicit CA file, then it should not be
on. I think I was hoping that openssl tied into some CA vault on
its own and a CA file was only necessary for non-public certs.

>  is global only, but since it's not a real
> directory/section itself anything can nest inside (including another
> )?

Any non-SSL directive inside would not be part of it. That could
lead to confusion, since other directives will not see the difference
and will not complain. I am not sure if introducing new section types,
which adds complexity in the server is worth it. We could add a section
to the documentation that states this limitation more clearly.

Also, nesting  should be prevented, as it will
not give the results that one would expect (I have not tested that,
but I think it would behave as if the two were side by side).

Cheers,

Stefan

Re: svn commit: r1824465 - /httpd/httpd/patches/2.4.x/mod_ssl_policy.diff

[Yann Ylavic]

Hi Stefan,

On Fri, Feb 16, 2018 at 2:05 PM,   wrote:
> Author: icing
> Date: Fri Feb 16 13:05:27 2018
> New Revision: 1824465
>
> URL: http://svn.apache.org/viewvc?rev=1824465=rev
> Log:
> sslpolicy patch for 2.4.x

Quick incomplete/review, two question...

There seems to be predefined/moz policies with "SSLProxyVerify
require" enforced, how can it work w/o a CA? That impose also setting
SSLProxyCACertificate* for httpd to start/work, right?

 is global only, but since it's not a real
directory/section itself anything can nest inside (including another
)?

Thanks,
Yann.