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 —
smime.p7s
Description: S/MIME cryptographic signature
