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 "<SSLPolicyDefine>" 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 <stefan.eiss...@greenbytes.de>:
> 
>> 
>> Am 16.02.2018 um 17:34 schrieb Yann Ylavic <ylavic....@gmail.com>:
>> 
>> Hi Stefan,
>> 
>> On Fri, Feb 16, 2018 at 2:05 PM,  <ic...@apache.org> wrote:
>>> Author: icing
>>> Date: Fri Feb 16 13:05:27 2018
>>> New Revision: 1824465
>>> 
>>> URL: http://svn.apache.org/viewvc?rev=1824465&view=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.
> 
>> <SSLPolicyDefine> is global only, but since it's not a real
>> directory/section itself anything can nest inside (including another
>> <SSLPolicyDefine>)?
> 
> 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 <SSLPolicyDefine> 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

Reply via email to