Charm support for configuring SSL/TLS protocols/ciphers

Bug #1851673 reported by David O Neill on 2019-11-07
260
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Charm Helpers
Undecided
Unassigned
OpenStack ceilometer charm
Wishlist
Unassigned
OpenStack ceph-radosgw charm
Wishlist
Unassigned
OpenStack cinder charm
Wishlist
Unassigned
OpenStack glance charm
Wishlist
Unassigned
OpenStack heat charm
Wishlist
Unassigned
OpenStack keystone charm
Wishlist
Unassigned
OpenStack neutron-api charm
Wishlist
Unassigned
OpenStack nova-cloud-controller charm
Wishlist
Unassigned
OpenStack openstack-dashboard charm
Wishlist
Unassigned
OpenStack swift-proxy charm
Wishlist
Unassigned

Bug Description

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) wrote :

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.

Changed in charm-openstack-dashboard:
status: New → Incomplete
Edin S (exsdev) wrote :

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/

Edin S (exsdev) on 2019-11-12
information type: Public → Public Security
Edin S (exsdev) on 2019-11-12
summary: - cipher
+ Charm support for configuring SSL/TLS protocols/ciphers
Edin S (exsdev) on 2019-11-12
Changed in charm-openstack-dashboard:
status: Incomplete → New
Andrew McLeod (admcleod) on 2020-03-03
Changed in charm-openstack-dashboard:
importance: Undecided → Wishlist
status: New → Triaged
Changed in charm-ceilometer:
importance: Undecided → Wishlist
status: New → Triaged
Changed in charm-ceph-radosgw:
importance: Undecided → Wishlist
status: New → Triaged
Changed in charm-cinder:
importance: Undecided → Wishlist
status: New → Triaged
Changed in charm-glance:
importance: Undecided → Wishlist
status: New → Triaged
Changed in charm-heat:
importance: Undecided → Wishlist
status: New → Triaged
Changed in charm-keystone:
importance: Undecided → Wishlist
status: New → Triaged
Changed in charm-neutron-api:
importance: Undecided → Wishlist
status: New → Triaged
Changed in charm-nova-cloud-controller:
importance: Undecided → Wishlist
status: New → Triaged
Changed in charm-swift-proxy:
importance: Undecided → Wishlist
status: New → Triaged
James Hebden (ec0) wrote :

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

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.

To post a comment you must log in.
This report contains Public Security information  Edit
Everyone can see this security related information.

Other bug subscribers