yahoo-eng-team team mailing list archive
-
yahoo-eng-team team
-
Mailing list archive
-
Message #79809
[Bug 1842149] [NEW] TLS ciphers/protocols are not configurable for console proxies
Public bug reported:
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.
** Affects: nova
Importance: Undecided
Status: New
--
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):
New
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
Follow ups
