[Bug 1892450] Re: Secure TLS configuration by default

[OpenStack Infra]

Reviewed:  https://review.opendev.org/c/openstack/charm-rabbitmq-server/+/817382
Committed: https://opendev.org/openstack/charm-rabbitmq-server/commit/ece87ba8ca0cf1450457c98c71166ef0b9a517a0
Submitter: "Zuul (22348)"
Branch:    master

commit ece87ba8ca0cf1450457c98c71166ef0b9a517a0
Author: James Page <james.page at ubuntu.com>
Date:   Wed Nov 10 10:21:22 2021 +0000

    Restrict TLS versions
    
    TLS < 1.2 is considered insecure; where possible limit the versions
    of TLS to 1.2 or higher, enabling support for TLS 1.3 when the
    required erlang and rabbitmq versions are installed.
    
    Change-Id: Iec5ab60488986f8e332ff0e9a11895822a61c1ee
    Closes-Bug: 1892450
    Func-Test-PR: https://github.com/openstack-charmers/zaza-openstack-tests/pull/668


** Changed in: charm-rabbitmq-server
       Status: In Progress => Fix Committed

-- 
You received this bug notification because you are a member of Ubuntu
OpenStack, which is subscribed to openvswitch in Ubuntu.
https://bugs.launchpad.net/bugs/1892450

Title:
  Secure TLS configuration by default

Status in OpenStack Ceilometer Charm:
  Fix Released
Status in Ceph RADOS Gateway Charm:
  Fix Released
Status in OpenStack Cinder Charm:
  Fix Released
Status in OpenStack Glance Charm:
  Fix Released
Status in OpenStack Heat Charm:
  Fix Released
Status in OpenStack Keystone Charm:
  Fix Released
Status in charm-layer-ovn:
  Invalid
Status in OpenStack Neutron API Charm:
  Fix Released
Status in OpenStack Nova Cloud Controller Charm:
  Fix Released
Status in OpenStack Octavia Charm:
  Fix Released
Status in OpenStack Dashboard Charm:
  Fix Released
Status in charm-ovn-central:
  Invalid
Status in OpenStack RabbitMQ Server Charm:
  Fix Committed
Status in OpenStack Swift Proxy Charm:
  Fix Released
Status in openvswitch package in Ubuntu:
  In Progress

Bug description:
  From the discussion on bug 1851673, I am opening this bug to track
  modernisation of TLS configuration across all OpenStack charms.

  It is important that the charms are providing opinionated, good
  practice defaults - we need to ensure TLS1.0 and TLS1.1 are removed
  from the supported ciphers as they are widely held to be deprecated
  and insecure. The current industry practice of disabling these TLS
  versions is described in the linked IETF draft: "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]

  In addition, we should downselect a good practice set of ciphers from
  the cross-section of ciphers with good client (browser, API client)
  support, and ciphers which follow current good cryptographic practice.

  A good baseline for this comes from the Apache project documentation
  [1] which in turn is based on Mozilla's security guidance around
  server-side TLS Ciphers [2].

  The below can be used to represent Mozilla's "intermediate"
  compatibility cipher suite, which enables TLS1.2 and TLS1.3. TLS1.2 is
  also important as I don't believe all shipped versions of apache2 with
  supported Ubuntu releases support TLS1.3 yet.

  SSLProtocol         all -SSLv3 -TLSv1 -TLSv1.1
  SSLCipherSuite ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES256-SHA:ECDHE-ECDSA-DES-CBC3-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:DES-CBC3-SHA:!DSS
  SSLHonorCipherOrder on
  SSLCompression      off
  SSLSessionTickets   off

  Users requiring insecure (or stronger!) cipher suites and versions
  would be able to customise them once 1851673 has been addressed, but
  until then, it would be simpler to give guidance around cipher
  support. For folks who need less secure configuration, we could simply
  give guidance around which specific charm releases support which TLS
  configurations. In my mind, having some users on older charm releases
  is better than blocking implementation of a more secure cipher suite
  on being able to customise the TLS configuration via charm settings.

  [0] https://tools.ietf.org/id/draft-ietf-tls-oldversions-deprecate-02.html#rfc.section.2
  [1] https://httpd.apache.org/docs/trunk/ssl/ssl_howto.html
  [2] https://wiki.mozilla.org/Security/Server_Side_TLS

To manage notifications about this bug go to:
https://bugs.launchpad.net/charm-ceilometer/+bug/1892450/+subscriptions