On 02 May 2017, at 3:19 PM, Stefan Eissing <stefan.eiss...@greenbytes.de> wrote:

> How can we help Mr and Ms Normal to stay up to date on these things?
> 
> - We cannot rewrite their config unasked. We need to be backward compatible.
> - Our defaults nowadays are dangerously unsafe, so users MUST do their own 
> settings.
> 
> I advocate that we need (yet another!) SSL directive where administrators can 
> declare their *intent*.
> 
> A. "I want my site safe and usable with modern browsers!"
> B. "I want a safe setting, but people with slightly out-dated clients should 
> be served as well."
> C. "I sadly need compatibility to some very old clients.”

This makes a lot of sense, and there is a lot of precedent for this.

AWS load balancers take an “intent” policy string based on a date, with the 
option of a “default” value:

http://docs.aws.amazon.com/elasticloadbalancing/latest/classic/ssl-config-update.html
------------------------------------------
|      DescribeLoadBalancerPolicies      |
+----------------------------------------+
|               PolicyName               |
+----------------------------------------+
|  ELBSecurityPolicy-2016-08             |
|  ELBSecurityPolicy-2015-05             |
|  ELBSecurityPolicy-2015-03             |
|  ELBSecurityPolicy-2015-02             |
|  ELBSecurityPolicy-2014-10             |
|  ELBSecurityPolicy-2014-01             |
|  ELBSecurityPolicy-2011-08             |
|  ELBSample-ELBDefaultCipherPolicy      |
|  ELBSample-OpenSSLDefaultCipherPolicy  |
+----------------------------------------+
Implementation wise, we could have a directive that is used to select the 
default values of various parameters, for example:

SSLSecurityLevel latest

or

SSLSecurityLevel 2017-05

Regards,
Graham
—

Attachment: smime.p7s
Description: S/MIME cryptographic signature

Reply via email to