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 <[email protected]>: > >> >> Am 16.02.2018 um 17:34 schrieb Yann Ylavic <[email protected]>: >> >> Hi Stefan, >> >> On Fri, Feb 16, 2018 at 2:05 PM, <[email protected]> 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
