Charm support for configuring SSL/TLS protocols/ciphers

Bug #1851673 reported by David O Neill
258
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Ceph RADOS Gateway Charm
Won't Fix
Wishlist
Unassigned
Charm Helpers
Won't Fix
Undecided
Unassigned
OpenStack Ceilometer Charm
Won't Fix
Wishlist
Unassigned
OpenStack Cinder Charm
Won't Fix
Wishlist
Unassigned
OpenStack Dashboard Charm
Won't Fix
Wishlist
Unassigned
OpenStack Glance Charm
Won't Fix
Wishlist
Unassigned
OpenStack Heat Charm
Won't Fix
Wishlist
Unassigned
OpenStack Keystone Charm
Won't Fix
Wishlist
Unassigned
OpenStack Neutron API Charm
Won't Fix
Wishlist
Unassigned
OpenStack Nova Cloud Controller Charm
Won't Fix
Wishlist
Unassigned
OpenStack Swift Proxy Charm
Won't Fix
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

Revision history for this message
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
Revision history for this message
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)
information type: Public → Public Security
Edin S (exsdev)
summary: - cipher
+ Charm support for configuring SSL/TLS protocols/ciphers
Edin S (exsdev)
Changed in charm-openstack-dashboard:
status: Incomplete → New
Andrew McLeod (admcleod)
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
Revision history for this message
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

Revision history for this message
Chris MacNaughton (chris.macnaughton) wrote :

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.

Revision history for this message
Billy Olsen (billy-olsen) wrote :

The charms have adopted tighter security regulations on TLS settings and these will not be configurable for the time being. I'm marking this as won't-fix, making it clear of our intentions.

Changed in charm-neutron-api:
status: Triaged → Won't Fix
Changed in charm-keystone:
status: Triaged → Won't Fix
Changed in charm-heat:
status: Triaged → Won't Fix
Changed in charm-glance:
status: Triaged → Won't Fix
Changed in charm-cinder:
status: Triaged → Won't Fix
Changed in charm-ceph-radosgw:
status: Triaged → Won't Fix
Changed in charm-ceilometer:
status: Triaged → Won't Fix
Changed in charm-helpers:
status: New → Won't Fix
Changed in charm-nova-cloud-controller:
status: Triaged → Won't Fix
Changed in charm-openstack-dashboard:
status: Triaged → Won't Fix
Changed in charm-swift-proxy:
status: Triaged → Won't Fix
To post a comment you must log in.
This report contains Public Security information  
Everyone can see this security related information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.