SSLPolicy

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

SSLPolicy

Stefan Eissing
Here is my proposal for more semantic sugar.

It defines 3 new SSL* config directives:

- <SSLPolicy name>      to define a set of SSL* directives under a name
- SSLPolicy             merge the non-proxy parts of the policy into the current server config. local directives will override
- SSLProxyPolicy        merge the proxy parts of the policy into the current server config. local directives will override

There are atm 3 predefined policies: modern, intermediate, old (from https://wiki.mozilla.org/Security/Server_Side_TLS)

In order to apply them on TLS connections to the client, you configure

  SSLPolicy modern

in your server config or in a specific vhost. To affect the backend proxy connections, you may add:

  SSLProxyPolicy intermediate

All settings beside a policy apply as usual. They do override policy values. The order does not matter:

  SSLPolicy modern
  SSLProtocol SSLv3

is the same as

  SSLProtocol SSLv3
  SSLPolicy modern

When you define multiple policy uses in the same server, they are merged in the reverse order
(or override each other in document order, e.g. last one wins):

  SSLPolicy modern
  SSLPolicy intermediate

will give you "intermediate" security settings, while

  SSLPolicy intermediate
  SSLPolicy modern

will give you "modern" ones.

You can override policies, so if someone wants to "hotfix" a policy, she can write:

<SSLPolicy modern>
  SSLPolicy modern
  SSLCipherSuite "VERYHOTNEWONE"
</SSLPolicy>

or you expand a policy:

<SSLPolicy modern-on>
  SSLPolicy modern
  SSLEngine on
</SSLPolicy>

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

Cheers,

-Stefan


ssl_policy_v2.diff (18K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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
[hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: SSLPolicy

Stefan Eissing


Am 14.08.2017 um 17:14 schrieb Eric Covener <[hidden email]>:

>> 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&Pop server goes https: it is just a bit easier to make it work with modern browsers.
>
> --
> Eric Covener
> [hidden email]

Reply | Threaded
Open this post in threaded view
|

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 <[hidden email]>:
>
>
>
> Am 14.08.2017 um 17:14 schrieb Eric Covener <[hidden email]>:
>
>>> 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&Pop server goes https: it is just a bit easier to make it work with modern browsers.
>>
>> --
>> Eric Covener
>> [hidden email]
>

Reply | Threaded
Open this post in threaded view
|

Re: SSLPolicy

Stefan Eissing
In reply to this post by Eric Covener

> Am 14.08.2017 um 17:14 schrieb Eric Covener <[hidden email]>:
>
>> 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.





> 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
> [hidden email]


ssl_policy_v3.diff (34K) Download Attachment