Charm support for configuring SSL/TLS protocols/ciphers

[David O Neill]

The charm needs to support changing apache cipher protocols/suites to meet customer IP security policies.

E.g
/etc/apache2/mods-enabled/ssl.conf

SSLProtocol all -SSLv2 -SSLv3 -TLSv1 -TLSv1.1 -TLSv1.2

thank you

[James Page (james-page)]

The charms should do sane things by default:

    SSLProtocol +TLSv1 +TLSv1.1 +TLSv1.2
    SSLCipherSuite HIGH:!RC4:!MD5:!aNULL:!eNULL:!EXP:!LOW:!MEDIUM

and be opinionated about what is secure based on recognised security standards.

So I'd prefer not to have an config option here but to review our default baseline for SSL TLS termination and update if need be.

[Edin S (exsdev)]

I agree with your statement on having opinionated, secure defaults.

In this case however I do believe that having a config override is a good idea.

Two examples come to mind (both based past experience):
1. A client may have a standard operating environment that mandates an
   older version of a browser (scary!) or Java version (e.g. JVM running an application that interacts with the OpenStack API). The client may wish to use old/insecure protocols/ciphers for compatibility reasons.

2. A client's independent pentester may recommend (e.g. flag as
   "MEDIUM" severity) that certain protocols/ciphers be disabled. The client may wish to disable protocols/ciphers that are still used "in the wild" (but not internally).

Mozilla provides a good SSL config generator that can be tweaked to give you some idea of how clients will be effected: https://ssl-config.mozilla.org/

[James Hebden (ec0)]

Per the guidance to ensure that charms are providing opinionated defaults - I don't believe it is crucial to enable customisation of the Ciphers, but we do need to ensure TLS1.0 and TLS1.1 are removed from the supported ciphers. It is now widely held that TLS1.0 and TLS1.1 are deprecated, and that we should be following industry practices: "Industry has actively followed guidance provided by NIST and the PCI Council to deprecate TLSv1.0 and TLSv1.1 by June 30, 2018. TLSv1.2 should remain a minimum baseline for TLS support at this time." [0]

[0] https://tools.ietf.org/id/draft-ietf-tls-oldversions-deprecate-02.html#rfc.section.2

[Chris MacNaughton (chris.macnaughton)]

Increasing the minimum cipher levels is a good idea; however, it isn't the same as making ciphers configurable so should be a separate bug.