SSLPolicy

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

SSLPolicy

Stefan Eissing
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 "<SSLPolicy":

  <SSLPolicy name>
    SSLProtocol      ...
    SSLCipherSuite   ...
    ...
  </SSLPolicy>

defines a set of SSL configuration directives (basically all non-proxy that are
applicable in vhosts). This can only be done in the global context. Names
may not be overwritten.

  SSLPolicy name

applies the policy in the given context (server/vhost).


Implementation:
Changes should basically only affect ssl_kernel_config.c. Config commands will
add a check if they are inside a "<SSLPolicy" selection and use a SSLSrvConfigRec*
for the section.
The config command for "SSLPolicy" will look up the SSLSrvConfigRec* of "name" in
a global hash and do a merge of that record with the current server one. This
should use the policy as base for the merge, so local directives can override a policy.

Compatibility:
Existing installations are unaffected by this addition.

-Stefan



Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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 "<SSLPolicy":
>
>    <SSLPolicy name>
>      SSLProtocol      ...
>      SSLCipherSuite   ...
>      ...
>    </SSLPolicy>
>
> defines a set of SSL configuration directives (basically all non-proxy that are
> applicable in vhosts). This can only be done in the global context. Names
> may not be overwritten.
>
>    SSLPolicy name
>
> applies the policy in the given context (server/vhost).
>
>
> Implementation:
> Changes should basically only affect ssl_kernel_config.c. Config commands will
> add a check if they are inside a "<SSLPolicy" selection and use a SSLSrvConfigRec*
> for the section.
> The config command for "SSLPolicy" will look up the SSLSrvConfigRec* of "name" in
> a global hash and do a merge of that record with the current server one. This
> should use the policy as base for the merge, so local directives can override a policy.
>
> Compatibility:
> Existing installations are unaffected by this addition.
>
> -Stefan
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: SSLPolicy

Luca Toscano
Hi Nick,

2017-08-04 13:06 GMT+02:00 Nick Gearls <[hidden email]>:
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 <a href="tel:04-08-2017%2011" value="+390408201711" target="_blank">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 
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: SSLPolicy

Jacob Champion-2
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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: SSLPolicy

William A Rowe Jr
In reply to this post by Stefan Eissing
On Fri, Aug 4, 2017 at 4:26 AM, Stefan Eissing
<[hidden email]> 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.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: SSLPolicy

Daniel Ruggeri
In reply to this post by Luca Toscano
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 <[hidden email]>
Sent: August 4, 2017 6:38:16 AM CDT
To: Apache HTTP Server Development List <[hidden email]>, [hidden email]
Subject: Re: SSLPolicy

Hi Nick,

2017-08-04 13:06 GMT+02:00 Nick Gearls <[hidden email]>:
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 <a href="tel:04-08-2017%2011" value="+390408201711" target="_blank">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 
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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 <[hidden email]> 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 <[hidden email]>
Sent: August 4, 2017 6:38:16 AM CDT
To: Apache HTTP Server Development List <[hidden email]>, [hidden email]
Subject: Re: SSLPolicy

Hi Nick,

2017-08-04 13:06 GMT+02:00 Nick Gearls <[hidden email]>:
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 <a href="tel:04-08-2017%2011" value="+390408201711" target="_blank">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 

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: SSLPolicy

Stefan Eissing
In reply to this post by William A Rowe Jr

> Am 04.08.2017 um 23:28 schrieb William A Rowe Jr <[hidden email]>:
>
> On Fri, Aug 4, 2017 at 4:26 AM, Stefan Eissing
> <[hidden email]> 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







Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: SSLPolicy

Stefan Eissing
In reply to this post by Gillis J. de Nijs

> Am 05.08.2017 um 13:28 schrieb Gillis J. de Nijs <[hidden email]>:
>
> 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 <[hidden email]> 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 <[hidden email]>
> Sent: August 4, 2017 6:38:16 AM CDT
> To: Apache HTTP Server Development List <[hidden email]>, [hidden email]
> Subject: Re: SSLPolicy
>
> Hi Nick,
>
> 2017-08-04 13:06 GMT+02:00 Nick Gearls <[hidden email]>:
> 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
>

Loading...