[Bug 1892450] Re: Secure TLS configuration by default

[Frode Nordahl]

>> OVN-Central/Chassis charm for review of TLS 1.2 in OVN
>
> The default behavior of the Open vSwitch clients and servers is to use the highest protocol version supported [0] and it has been this way since Open vSwitch v2.4.0 [1] which was released in 2014.
>
> The default configuration does allow the use of TLSv1,TLSv1.1,TLSv1.2, so if the intention of this bug is to disallow protocol versions prior to TLSv1.2 that would translate into action necessary for the OVN charms.
>
> 0: http://manpages.ubuntu.com/manpages/focal/man1/ovsdb-server.1.html
> 1: https://github.com/openvswitch/ovs/commit/b56ea5d54e072105b398d26421f9a4578fa6e05b

Just an update on the Open vSwitch part of this bug.  While the above is
true, and there is an outstanding issue of updating the Open vSwitch
defaults and documentation, due to how the defaults are set up for the
OpenSSL library in Ubuntu, Open vSwitch and OVN is in effect not
affected by this.

The Ubuntu OpenSSL library configuration will make Open vSwitch and OVN
only enable TLSv1.2 and TLSv1.3 as long as no configuration is provided
for the SSL_Protocols and SSL_Ciphers options.

** Changed in: charm-layer-ovn
       Status: Confirmed => Invalid

** Changed in: charm-ovn-central
       Status: Confirmed => Invalid

-- 
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 OpenStack ceph-radosgw 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 openstack-dashboard charm:
  Fix Released
Status in charm-ovn-central:
  Invalid
Status in OpenStack rabbitmq-server charm:
  In Progress
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