yahoo-eng-team team mailing list archive

[OpenStack Infra <1842149@xxxxxxxxxxxxxxxxxx>]

Reviewed:  https://review.opendev.org/679502
Committed: https://git.openstack.org/cgit/openstack/nova/commit/?id=08bdcdb5b6866c2b6bf084344cca4dd07b960133
Submitter: Zuul
Branch:    master

commit 08bdcdb5b6866c2b6bf084344cca4dd07b960133
Author: Nathan Kinder <nkinder@xxxxxxxxxx>
Date:   Fri Aug 30 12:24:03 2019 -0700

    Allow TLS ciphers/protocols to be configurable for console proxies
    
    The console proxies (VNC, SPICE, etc) currently don't allow the
    allowed TLS ciphers and protocol versions to be configurable.  This
    results in the defaults being used from the underlying system,
    which may not be secure enough for many deployments.  This patch
    allows for the ciphers and minimum SSL/TLS protocol version for
    each console proxy to be configured in nova's config.
    
    We utilize websockify underneath our console proxies, which added
    support for allowed ciphers and the SSL/TLS version to be
    configurable as of version 0.9.0.  This change updates the lower
    constraint for this dependency.
    
    Closes-Bug: #1842149
    Related-Bug: #1771773
    Change-Id: I23ac1cc79482d0fabb359486a4b934463854cae5


** Changed in: nova
       Status: In Progress => Fix Released

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Compute (nova).
https://bugs.launchpad.net/bugs/1842149

Title:
  TLS ciphers/protocols are not configurable for console proxies

Status in OpenStack Compute (nova):
  Fix Released

Bug description:
  Description
  ===========

  The console proxies (VNC, SPICE, etc) currently don't allow the
  allowed TLS ciphers and protocol versions to be configurable.  This
  results in the defaults being used from the underlying system (or even
  compiled defaults in OpenSSL), which may not be secure enough for many
  deployments.

  For example, many commonly used distributions have compiled-in OpenSSL
  library defaults that allow things like SSLv3 and TLSv1.0 due to
  backwards compatibility concerns.  This is often fine, as applications
  are expected to override the defaults if they want to be more secure,
  but we can't do that currently in nova.

  Steps to reproduce
  ==================

  - Deploy nova and configure the VNC proxy with TLS by setting the
  'cert' and 'key' options in the '[vnc]' section.

  - Utilize a tool such as nmap, 'openssl s_client', or an approach like
  https://superuser.com/questions/109213/how-do-i-list-the-ssl-tls-
  cipher-suites-a-particular-website-offers to scan the VNC proxy port
  for the allowed TLS ciphers and protocols.  Here is an few examples of
  these methods:

  $ openssl s_client -ssl3 -connect 192.168.24.26:6080
  CONNECTED(00000003)
  ...snipped for brevity...
  ---
  SSL handshake has read 1816 bytes and written 298 bytes
  ---
  New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-SHA
  Server public key is 2048 bit
  Secure Renegotiation IS supported
  Compression: NONE
  Expansion: NONE
  No ALPN negotiated
  SSL-Session:
      Protocol  : SSLv3
      Cipher    : ECDHE-RSA-AES256-SHA
      Session-ID: F81B02A16309AACDF3019EA808A952C97E902D5A1BDA26CB47468B546B33BDC6
      Session-ID-ctx: 
      Master-Key: FA2990F148ACBAE3697B3D88E71BFAF7739642D844178C7AE220BC42B5EA67CA5A4ACD79824123C83FC7DAC4D848417C
      Key-Arg   : None
      Krb5 Principal: None
      PSK identity: None
      PSK identity hint: None
      Start Time: 1567199209
      Timeout   : 7200 (sec)
      Verify return code: 0 (ok)
  ---
  ...snipped for brevity...

  
  $ nmap --script +ssl-enum-ciphers -p 6080 192.168.24.26

  Starting Nmap 6.40 ( http://nmap.org ) at 2019-08-30 20:47 UTC
  Nmap scan report for overcloud-controller-0.ooo.test (192.168.24.26)
  Host is up (0.00010s latency).
  PORT     STATE SERVICE
  6080/tcp open  unknown
  | ssl-enum-ciphers: 
  |   SSLv3: 
  |     ciphers: 
  |       TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA - strong
  |       TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA - strong
  |       TLS_ECDHE_RSA_WITH_RC4_128_SHA - strong
  |       TLS_RSA_WITH_AES_128_CBC_SHA - strong
  |       TLS_RSA_WITH_AES_256_CBC_SHA - strong
  |       TLS_RSA_WITH_CAMELLIA_128_CBC_SHA - strong
  |       TLS_RSA_WITH_CAMELLIA_256_CBC_SHA - strong
  |       TLS_RSA_WITH_RC4_128_SHA - strong
  |     compressors: 
  |       NULL
  |   TLSv1.0: 
  |     ciphers: 
  |       TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA - strong
  |       TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA - strong
  |       TLS_ECDHE_RSA_WITH_RC4_128_SHA - strong
  |       TLS_RSA_WITH_AES_128_CBC_SHA - strong
  |       TLS_RSA_WITH_AES_256_CBC_SHA - strong
  |       TLS_RSA_WITH_CAMELLIA_128_CBC_SHA - strong
  |       TLS_RSA_WITH_CAMELLIA_256_CBC_SHA - strong
  |       TLS_RSA_WITH_RC4_128_SHA - strong
  |     compressors: 
  |       NULL
  |   TLSv1.1: 
  |     ciphers: 
  |       TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA - strong
  |       TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA - strong
  |       TLS_ECDHE_RSA_WITH_RC4_128_SHA - strong
  |       TLS_RSA_WITH_AES_128_CBC_SHA - strong
  |       TLS_RSA_WITH_AES_256_CBC_SHA - strong
  |       TLS_RSA_WITH_CAMELLIA_128_CBC_SHA - strong
  |       TLS_RSA_WITH_CAMELLIA_256_CBC_SHA - strong
  |       TLS_RSA_WITH_RC4_128_SHA - strong
  |     compressors: 
  |       NULL
  |   TLSv1.2: 
  |     ciphers: 
  |       TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA - strong
  |       TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 - strong
  |       TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 - strong
  |       TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA - strong
  |       TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 - strong
  |       TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 - strong
  |       TLS_ECDHE_RSA_WITH_RC4_128_SHA - strong
  |       TLS_RSA_WITH_AES_128_CBC_SHA - strong
  |       TLS_RSA_WITH_AES_128_CBC_SHA256 - strong
  |       TLS_RSA_WITH_AES_128_GCM_SHA256 - strong
  |       TLS_RSA_WITH_AES_256_CBC_SHA - strong
  |       TLS_RSA_WITH_AES_256_CBC_SHA256 - strong
  |       TLS_RSA_WITH_AES_256_GCM_SHA384 - strong
  |       TLS_RSA_WITH_CAMELLIA_128_CBC_SHA - strong
  |       TLS_RSA_WITH_CAMELLIA_256_CBC_SHA - strong
  |       TLS_RSA_WITH_RC4_128_SHA - strong
  |     compressors: 
  |       NULL
  |_  least strength: strong

  
  Expected result
  ===============
  Insecure protocols such as SSLv3 and TLS1.0 should not succeed for connections via 'openssl s_client', and insecure ciphers should not be listed, or it should be possible to disable ciphers/protocols such as there for the console proxies.

  
  We utilize websockify underneath our console proxies, which added support for allowed ciphers and protocol versions to be configurable as of version 0.9.0.  If we update the websockify version we require, the TLS cipher and protocol settings could be configured in nova.conf to allow thins to be hardened today as well as allowing for crypto-agility in the future.  While this would require new (optional) configuration options in nova, I consider this issue to be more of a bug than a feature given that we are forcing people to be using known broken crypto in some cases.

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1842149/+subscriptions