Re: SSLPolicy code questions/backport review

[Stefan Eissing]

Since parts of the changes in mod_ssl for SSLPolicy have now been affected
by changes for TLSv1.3 and there has not been real interest in backporting
SSLPolicy this year anyway, I withdraw the proposal.

The TLSv1.3 changes are not fit for backport since I was unable to verify
that my fixes to client certificate handling were working (I have no working
test setup for that). So, I cleaned up after Joe's review and that's it.

If someone has the energy/interest in backporting any of this, feel free.

-Stefan

In more detail inline:

> Am 23.05.2018 um 09:51 schrieb Joe Orton :
> 
> Easier to do here than dump in STATUS; looking at reviewing the 2.4.x 
> backport:
> 
> https://svn.apache.org/repos/asf/httpd/httpd/patches/2.4.x/ssl-policy.patch 
> 
> 0. Overall looks good, I like the way this has been done!

Thanks.

> 1. Is there a reason why we need SSLPolicyRec with (name, sc) members 
> rather than having a hash directly of SSLSrvConfigRec *?  The only time 
> ->name is used seems to be when creating the hash in add_policy().  
> [Reading back through commits, I guess this was a legacy of having ->dc 
> in there too]
> 
> 2. Storing the policies hash off pconf userdata seems surprising, is 
> there a reason that's done rather than putting it directly in 
> SSLModConfigRec?

They are also looked up during configuration where SSLModConfigRec
may is not available. See ssl_engine_config.c, line 608

> 3. get_policy_names() seems be only now called with create=1, and hence 
> the same is true for get_policies(), so there are some redundant paths + 
> redundant arguments here which could be removed?

I'll eliminiate the parameter.

> 
> 4. There is a bunch of legacy from the now-removed SSLPolicyDefine 
> AFAICT still included on trunk (not in the 2.4 patch); there is a 
> reference added in the docs in the 2.4 patch though. e.g.
> 
> BOOL ssl_config_global_isfixed(SSLModConfigRec *mc)
> {
> -return mc->bFixed;
> +return mc && mc->bFixed;
> 
> is I think related and in trunk all the ssl_cmd_* handling of mc==NULL 
> case (again not in the backport).

I'll revert that change. It caused crashes when indirectly called during
configuration, as was the case in policy definition, I think.

> 5. Very minor, please don't reformat the code now, but httpd code style 
> has case X: statements lined up with switch rather than indented.

Uhm...ok?

> Regards, Joe

Re: SSLPolicy code questions/backport review

[Stefan Eissing]

Thanks for the review! I will take this and clean up the code, mod_ssl 
certainly deserves it.

> Am 23.05.2018 um 09:51 schrieb Joe Orton :
> 
> Easier to do here than dump in STATUS; looking at reviewing the 2.4.x 
> backport:
> 
> https://svn.apache.org/repos/asf/httpd/httpd/patches/2.4.x/ssl-policy.patch 
> 
> 0. Overall looks good, I like the way this has been done!
> 
> 1. Is there a reason why we need SSLPolicyRec with (name, sc) members 
> rather than having a hash directly of SSLSrvConfigRec *?  The only time 
> ->name is used seems to be when creating the hash in add_policy().  
> [Reading back through commits, I guess this was a legacy of having ->dc 
> in there too]
> 
> 2. Storing the policies hash off pconf userdata seems surprising, is 
> there a reason that's done rather than putting it directly in 
> SSLModConfigRec?
> 
> 3. get_policy_names() seems be only now called with create=1, and hence 
> the same is true for get_policies(), so there are some redundant paths + 
> redundant arguments here which could be removed?
> 
> 4. There is a bunch of legacy from the now-removed SSLPolicyDefine 
> AFAICT still included on trunk (not in the 2.4 patch); there is a 
> reference added in the docs in the 2.4 patch though. e.g.
> 
> BOOL ssl_config_global_isfixed(SSLModConfigRec *mc)
> {
> -return mc->bFixed;
> +return mc && mc->bFixed;
> 
> is I think related and in trunk all the ssl_cmd_* handling of mc==NULL 
> case (again not in the backport).
> 
> 5. Very minor, please don't reformat the code now, but httpd code style 
> has case X: statements lined up with switch rather than indented.
> 
> Regards, Joe

Re: SSLPolicy

[Stefan Eissing]

> Am 14.08.2017 um 17:14 schrieb Eric Covener :
> 
>> I hope this looks attractive to you. All bugs are mine. Let me know what you 
>> think.
> 
> It looks neat.  I think accessible doc will be key.

This is now addressed in v3 (attached below): I added DUMP code that lists all 
dfined SSLPolicy records (it could dump basically all srv and dir configs, if 
one so desires). Invoke with

> httpd -t -D DUMP_SSL_POLICIES

On an empty, patched server, this gives:

SSLPolicies: {
  "intermediate": {
"SSLCompression": "off", 
"SSLProtocol": "+TLSv1.2 +TLSv1.1 +TLSv1.0", 
"SSLCipherSuite": 
"ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES256-SHA:ECDHE-ECDSA-DES-CBC3-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:DES-CBC3-SHA:!DSS",
 
"SSLSessionTickets": "off", 
"SSLProxyProtocol": "+TLSv1.2 +TLSv1.1 +TLSv1.0", 
"SSLProxyCipherSuite": 
"ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES256-SHA:ECDHE-ECDSA-DES-CBC3-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:DES-CBC3-SHA:!DSS",
 
"SSLProxyVerify": "require"
  }, 
  "modern": {
"SSLCompression": "off", 
"SSLProtocol": "+TLSv1.2", 
"SSLCipherSuite": 
"ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256",
 
"SSLSessionTickets": "off", 
"SSLProxyProtocol": "+TLSv1.2", 
"SSLProxyCipherSuite": 
"ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256",
 
"SSLProxyVerify": "require"
  }, 
  "old": {
"SSLCompression": "off", 
"SSLProtocol": "all", 
"SSLCipherSuite": 
"ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:ECDHE-RSA-DES-CBC3-SHA:ECDHE-ECDSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:AES:DES-CBC3-SHA:HIGH:SEED:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!RSAPSK:!aDH:!aECDH:!EDH-DSS-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA:!SRP",
 
"SSLSessionTickets": "off", 
"SSLProxyProtocol": "all", 
"SSLProxyCipherSuite": 
"ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:ECDHE-RSA-DES-CBC3-SHA:ECDHE-ECDSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:AES:DES-CBC3-SHA:HIGH:SEED:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!RSAPSK:!aDH:!aECDH:!EDH-DSS-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA:!SRP",
 
"SSLProxyVerify": "none"
  }
}

On a configured server, you see all SSL policies as they have been defined in 
the config files.



ssl_policy_v3.diff
Description: Binary data



> But for the sake of 

Re: SSLPolicy

[Stefan Eissing]

Woah! I just read ssl_init_ctx_protocol()...that's... quite something.

So, basically, what our SSLProtocol does is
- select the proper _new() variant for the SSL_CTX_new()
- disable known protocol versions not set in our bitmask
- set the max protocol version based on our bitmask

What does that mean if someone wants to configure TLSv1.3 for their server?

Do I read this correctly that we need to make a new release first before
someone can enable it?


-Stefan

> Am 14.08.2017 um 18:56 schrieb Stefan Eissing :
> 
> 
> 
> Am 14.08.2017 um 17:14 schrieb Eric Covener :
> 
>>> I hope this looks attractive to you. All bugs are mine. Let me know what 
>>> you think.
>> 
>> It looks neat.  I think accessible doc will be key.
> 
> yes. I was thinking of generating, but had no bright idea so far.
> 
>> But for the sake of discussion, what will we do / what will
>> distributors do when say TLS1.3 or some esoteric part of it is only
>> available in some SSL toolkit releases?
> 
> Well, the protocol defs do not exclude anything new. So TLS1.3 will just be 
> "on" where available. 
> 
>> It seems like over time there are a lot of confusion with compile-time
>> vs. runtime openssl, forks, etc that either push towards "modern"
>> being ambiguous for a user or to have lots of different permutations
>> defined.
> 
> That is rather the description of the state SSL configs is in now, is it not? 
> Apart from the few who really know everyone copies sth from somewhere. 
> 
> And they can continue to do so. We take nothing away. We just offer them, 
> hopefully, an easier way to define what they like. 
> 
> Plus some predefined policies for people that just want to use sth we offer. 
> The rate of change should be very low, I think.
> 
> If a Mom server goes https: it is just a bit easier to make it work with 
> modern browsers. 
>> 
>> -- 
>> Eric Covener
>> cove...@gmail.com
> 

Re: SSLPolicy

[Stefan Eissing]

Am 14.08.2017 um 17:14 schrieb Eric Covener :

>> I hope this looks attractive to you. All bugs are mine. Let me know what you 
>> think.
> 
> It looks neat.  I think accessible doc will be key.

yes. I was thinking of generating, but had no bright idea so far.

> But for the sake of discussion, what will we do / what will
> distributors do when say TLS1.3 or some esoteric part of it is only
> available in some SSL toolkit releases?

Well, the protocol defs do not exclude anything new. So TLS1.3 will just be 
"on" where available. 

> It seems like over time there are a lot of confusion with compile-time
> vs. runtime openssl, forks, etc that either push towards "modern"
> being ambiguous for a user or to have lots of different permutations
> defined.

That is rather the description of the state SSL configs is in now, is it not? 
Apart from the few who really know everyone copies sth from somewhere. 

And they can continue to do so. We take nothing away. We just offer them, 
hopefully, an easier way to define what they like. 

Plus some predefined policies for people that just want to use sth we offer. 
The rate of change should be very low, I think.

If a Mom server goes https: it is just a bit easier to make it work with 
modern browsers. 
> 
> -- 
> Eric Covener
> cove...@gmail.com

Re: SSLPolicy

[Eric Covener]

> I hope this looks attractive to you. All bugs are mine. Let me know what you 
> think.

It looks neat.  I think accessible doc will be key.

But for the sake of discussion, what will we do / what will
distributors do when say TLS1.3 or some esoteric part of it is only
available in some SSL toolkit releases?
It seems like over time there are a lot of confusion with compile-time
vs. runtime openssl, forks, etc that either push towards "modern"
being ambiguous for a user or to have lots of different permutations
defined.

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

Re: SSLPolicy

[Stefan Eissing]

> Am 05.08.2017 um 13:28 schrieb Gillis J. de Nijs <gil...@jink.net>:
> 
> When you use Let's Encrypt, the default is to include 
> /etc/letsencrypt/options-ssl-apache.conf in your config.  That's (presumably) 
> updated whenever you update the certbot package.  Similarly, I suppose you 
> can just put your own SSL settings in a file that you include.  I was trying 
> some settings, so I have /etc/apache2/ssl/cipherlist-strong.conf and 
> /etc/apache2/ssl/mozilla-modern.conf for example.  But I don't think this 
> allows for merging of policies.

As you might know, I am working on getting Let's Encrypt certificates into 
Apache natively. So, I am looking for ways to provide easy SSL configurations 
for people that ship with Apache (the configs, not the people). Without 
affecting any existing configs and without taking anything away from operators, 
of course.
 
-Stefan

> On Sat, Aug 5, 2017 at 2:17 AM, Daniel Ruggeri <drugg...@primary.net> wrote:
> If I extrapolate on the idea of what Nick is saying, it sounds like it could 
> be a proposal to simply define these SSL policies in a macro. Personally, I 
> prefer that approach over adding another set of directives (but it's a 
> preference, not an opposition). The downside is that mod_macro would need to 
> be loaded to take advantage of the macros we define. Surely some autoconf 
> magics could be used that say 'if mod_macro and mod_ssl are compiled, render 
> this set of macros in the ssl section.'
> -- 
> Daniel Ruggeri
> 
> From: Luca Toscano <toscano.l...@gmail.com>
> Sent: August 4, 2017 6:38:16 AM CDT
> To: Apache HTTP Server Development List <dev@httpd.apache.org>, 
> nickgea...@gmail.com
> Subject: Re: SSLPolicy
> 
> Hi Nick,
> 
> 2017-08-04 13:06 GMT+02:00 Nick Gearls <nickgea...@gmail.com>:
> This can be done using mod_macro without any additional code
> 
> my 2c: Stefan's point is to simplify the management of things that have been 
> done up to now using workarounds and elegant hacks:
>  
> On 04-08-2017 11:26, Stefan Eissing wrote:
> 
> The Benefits I'd like to achieve with this:
> A. A name makes it easier to talk about used/recommended configurations. It
> also makes it easy for admins to apply a known set of policies. It is
> less error prone.
> B. SSLPolicy definitions can be updated by us or by distributions, since the
> config defining the policies need not be edited by the user, e.g. can be
> replaced in an update. This way, a broken cipher/protocol can be updated
> away in policies we/distributions define. This should help increase 
> security
> of https on the internet.
> 
> I agree that mod_macro is flexible enough to improve the reusability of 
> httpd's configuration, but I don't think that the goals that Stefan has in 
> mind are satisfiable with your proposed solution.
> 
> Luca 
> 

Re: SSLPolicy

[Stefan Eissing]

> Am 04.08.2017 um 23:28 schrieb William A Rowe Jr :
> 
> On Fri, Aug 4, 2017 at 4:26 AM, Stefan Eissing
>  wrote:
>> I talked about some kind of SSL Policy definition in httpd's configuration
>> in the past and am now about to get serious about it. Here is what I wan to
>> do:
>> 
>> Recap: the general idea is
>> 2. Provide a set of already defined policies that either follow a public
>>   definition (like the Mozilla security classes) or express our idea of
>>   how configuration should look like.
> 
> I read this aspect at this as more of a weakness than a benefit.
> 
> OpenSSL is more likely to be promptly updated by our users than httpd
> itself. Where ever httpd is overriding OpenSSL preferences, we will
> simply be prolonging the use of discouraged policy.
> 
> If a cipher is changed upstream in OpenSSL from HIGH to MEDIUM
> strength (or dropped entirely), due to the discovery of a weakness in
> the cipher, I believe it is important for httpd to pick up on that signal
> without upgrade or recompilation.

That is not a matter of SSLPolicy or not, but how one uses SSLCipherSuite,
inside or outside SSLPolicy. 

If someone configures nowadays an explicit cipher list (and not something 
like HIGH, MEDIUM), she does also not benefit from any OpenSSL updates in 
this regards.

I talked with the OpenSSL team during the HTTP/2 development, why they
do not take the Browser cipher requirements into their keyword definitions.
At that time, the answer basically was that they see HTTP as just one
layer up (among others) with which they are not directly concerned about 
and, if one wanted, one could add such definitions into the ssl config 
files.

So, not their problem. 

Yikes! Let's check what people search for secure httpd ssl configs
actually might find (this got a bit long, but bear with me):


A duckduckgo search for "httpd secure ssl config" has as first hit for me
https://www.centos.org/docs/5/html/Deployment_Guide-en-US/s1-httpd-secure-server.html
which talks about how to get a certificate and install that into httpd but
says *nothing* about protocols or ciphers. The "additional resources" links
to our website (good) and to http://www.modssl.org which says:
"Current Version: mod_ssl 2.8.31 for Apache 1.3.41"

This might mean
* duckduckgo thinks I am old fashioned
* there are no better descriptions on the web (not true, I know)
* many sites refer to this centos doc and many people use it

DoubleYikes!

Back to our site: 
http://httpd.apache.org/docs/current/en/ssl/ssl_howto.html#onlystrong
Our "only strong" recommendation for good performance is:

SSLCipherSuite RC4-SHA:AES128-SHA:HIGH:!aNULL:!MD5

Now, I am not the ultimate expert on this, but as I read Ivan Ristić this
is not really recommended nowadays any more. (Here is SSLLabs doc on
SSL config advice 
https://github.com/ssllabs/research/wiki/SSL-and-TLS-Deployment-Best-Practices
which is generic for all servers).

Then, more interesting, people might stumble on the "Mozilla SSL Configuration 
Generator"
at https://mozilla.github.io/server-side-tls/ssl-config-generator/ 
which gives a complete Apache configuration where you select version and
your security policy (ahem) and people will get:

SSLCipherSuite  
ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES256-SHA:ECDHE-ECDSA-DES-CBC3-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:DES-CBC3-SHA:!DSS

I would guess that this is what people *copy* into their server configs
and which then will get never, or only sporadically updated. 

TripleYikes!

So, the question is: what do we want this generator actually to say?
My idea is that when people select Apache httpd 2.4.28, they will see

SSLPolicy modern

instead. And I do not see how that can work with mod_macro as well as
with a mod_ssl config directive. But I am listening.

Thanks for the patience,

-Stefan

Re: SSLPolicy

[Gillis J. de Nijs]

When you use Let's Encrypt, the default is to
include /etc/letsencrypt/options-ssl-apache.conf in your config.  That's
(presumably) updated whenever you update the certbot package.  Similarly, I
suppose you can just put your own SSL settings in a file that you include.
I was trying some settings, so I have
/etc/apache2/ssl/cipherlist-strong.conf and
/etc/apache2/ssl/mozilla-modern.conf for example.  But I don't think this
allows for merging of policies.

On Sat, Aug 5, 2017 at 2:17 AM, Daniel Ruggeri <drugg...@primary.net> wrote:

> If I extrapolate on the idea of what Nick is saying, it sounds like it
> could be a proposal to simply define these SSL policies in a macro.
> Personally, I prefer that approach over adding another set of directives
> (but it's a preference, not an opposition). The downside is that mod_macro
> would need to be loaded to take advantage of the macros we define. Surely
> some autoconf magics could be used that say 'if mod_macro and mod_ssl are
> compiled, render this set of macros in the ssl section.'
> --
> Daniel Ruggeri
>
> --
> *From:* Luca Toscano <toscano.l...@gmail.com>
> *Sent:* August 4, 2017 6:38:16 AM CDT
> *To:* Apache HTTP Server Development List <dev@httpd.apache.org>,
> nickgea...@gmail.com
> *Subject:* Re: SSLPolicy
>
> Hi Nick,
>
> 2017-08-04 13:06 GMT+02:00 Nick Gearls <nickgea...@gmail.com>:
>
>> This can be done using mod_macro without any additional code
>
>
> my 2c: Stefan's point is to simplify the management of things that have
> been done up to now using workarounds and elegant hacks:
>
>
>> On 04-08-2017 11:26, Stefan Eissing wrote:
>>>
>>>
>>> The Benefits I'd like to achieve with this:
>>> A. A name makes it easier to talk about used/recommended configurations.
>>> It
>>> also makes it easy for admins to apply a known set of policies. It is
>>> less error prone.
>>> B. SSLPolicy definitions can be updated by us or by distributions, since
>>> the
>>> config defining the policies need not be edited by the user, e.g.
>>> can be
>>> replaced in an update. This way, a broken cipher/protocol can be
>>> updated
>>> away in policies we/distributions define. This should help increase
>>> security
>>> of https on the internet.
>>>
>>
> I agree that mod_macro is flexible enough to improve the reusability of
> httpd's configuration, but I don't think that the goals that Stefan has in
> mind are satisfiable with your proposed solution.
>
> Luca
>

Re: SSLPolicy

[Daniel Ruggeri]

If I extrapolate on the idea of what Nick is saying, it sounds like it could be 
a proposal to simply define these SSL policies in a macro. Personally, I prefer 
that approach over adding another set of directives (but it's a preference, not 
an opposition). The downside is that mod_macro would need to be loaded to take 
advantage of the macros we define. Surely some autoconf magics could be used 
that say 'if mod_macro and mod_ssl are compiled, render this set of macros in 
the ssl section.'
-- 
Daniel Ruggeri


 Original Message 
From: Luca Toscano <toscano.l...@gmail.com>
Sent: August 4, 2017 6:38:16 AM CDT
To: Apache HTTP Server Development List <dev@httpd.apache.org>, 
nickgea...@gmail.com
Subject: Re: SSLPolicy

Hi Nick,

2017-08-04 13:06 GMT+02:00 Nick Gearls <nickgea...@gmail.com>:

> This can be done using mod_macro without any additional code


my 2c: Stefan's point is to simplify the management of things that have
been done up to now using workarounds and elegant hacks:


> On 04-08-2017 11:26, Stefan Eissing wrote:
>>
>>
>> The Benefits I'd like to achieve with this:
>> A. A name makes it easier to talk about used/recommended configurations.
>> It
>> also makes it easy for admins to apply a known set of policies. It is
>> less error prone.
>> B. SSLPolicy definitions can be updated by us or by distributions, since
>> the
>> config defining the policies need not be edited by the user, e.g. can
>> be
>> replaced in an update. This way, a broken cipher/protocol can be
>> updated
>> away in policies we/distributions define. This should help increase
>> security
>> of https on the internet.
>>
>
I agree that mod_macro is flexible enough to improve the reusability of
httpd's configuration, but I don't think that the goals that Stefan has in
mind are satisfiable with your proposed solution.

Luca

Re: SSLPolicy

[William A Rowe Jr]

On Fri, Aug 4, 2017 at 4:26 AM, Stefan Eissing
 wrote:
> I talked about some kind of SSL Policy definition in httpd's configuration
> in the past and am now about to get serious about it. Here is what I wan to
> do:
>
> Recap: the general idea is
> 2. Provide a set of already defined policies that either follow a public
>definition (like the Mozilla security classes) or express our idea of
>how configuration should look like.

I read this aspect at this as more of a weakness than a benefit.

OpenSSL is more likely to be promptly updated by our users than httpd
itself. Where ever httpd is overriding OpenSSL preferences, we will
simply be prolonging the use of discouraged policy.

If a cipher is changed upstream in OpenSSL from HIGH to MEDIUM
strength (or dropped entirely), due to the discovery of a weakness in
the cipher, I believe it is important for httpd to pick up on that signal
without upgrade or recompilation.

Re: SSLPolicy

[Jacob Champion]

On 08/04/2017 04:38 AM, Luca Toscano wrote:
I agree that mod_macro is flexible enough to improve the reusability of 
httpd's configuration, but I don't think that the goals that Stefan has 
in mind are satisfiable with your proposed solution.


If we find ourselves doing more of this syntactic sugar stuff -- 
grouping related directives into meta-directives -- I think it'd be nice 
to extend mod_macro to the point that we can build those meta-directives 
using its functionality directly, and then fold that into core.


For now, though, I'm ++1 to Stefan's concept. We can see how much 
extra/duplicate code there is and try to refactor it up as we go.


--Jacob

Re: SSLPolicy

[Luca Toscano]

Hi Nick,

2017-08-04 13:06 GMT+02:00 Nick Gearls :

> This can be done using mod_macro without any additional code


my 2c: Stefan's point is to simplify the management of things that have
been done up to now using workarounds and elegant hacks:


> On 04-08-2017 11:26, Stefan Eissing wrote:
>>
>>
>> The Benefits I'd like to achieve with this:
>> A. A name makes it easier to talk about used/recommended configurations.
>> It
>> also makes it easy for admins to apply a known set of policies. It is
>> less error prone.
>> B. SSLPolicy definitions can be updated by us or by distributions, since
>> the
>> config defining the policies need not be edited by the user, e.g. can
>> be
>> replaced in an update. This way, a broken cipher/protocol can be
>> updated
>> away in policies we/distributions define. This should help increase
>> security
>> of https on the internet.
>>
>
I agree that mod_macro is flexible enough to improve the reusability of
httpd's configuration, but I don't think that the goals that Stefan has in
mind are satisfiable with your proposed solution.

Luca

Re: SSLPolicy

[Nick Gearls]

This can be done using mod_macro without any additional code

On 04-08-2017 11:26, Stefan Eissing wrote:

I talked about some kind of SSL Policy definition in httpd's configuration
in the past and am now about to get serious about it. Here is what I wan to
do:

Recap: the general idea is
1. Give a set of SSL directives a name and allow the user to apply that name
in several virtual hosts.
2. Provide a set of already defined policies that either follow a public
definition (like the Mozilla security classes) or express our idea of
how configuration should look like.
3. Allow distributions/users to define their own policy sets, of course.

The Benefits I'd like to achieve with this:
A. A name makes it easier to talk about used/recommended configurations. It
also makes it easy for admins to apply a known set of policies. It is
less error prone.
B. SSLPolicy definitions can be updated by us or by distributions, since the
config defining the policies need not be edited by the user, e.g. can be
replaced in an update. This way, a broken cipher/protocol can be updated
away in policies we/distributions define. This should help increase security
of https on the internet.

The proposal:

Introduce two new directives "SSLPolicy" and "