Merge "Websockify security proxy framework"
This commit is contained in:
Jenkins
Gerrit Code Review
commit
b80246b71d
367
specs/pike/approved/websocket-proxy-to-host-security.rst
Normal file
367
specs/pike/approved/websocket-proxy-to-host-security.rst
Normal file
@ -0,0 +1,367 @@
|
|||||||
|
..
|
||||||
|
This work is licensed under a Creative Commons Attribution 3.0 Unported
|
||||||
|
License.
|
||||||
|
|
||||||
|
http://creativecommons.org/licenses/by/3.0/legalcode
|
||||||
|
|
||||||
|
===================================================================
|
||||||
|
Support Proxying of Encryption and Authentication in WebSocketProxy
|
||||||
|
===================================================================
|
||||||
|
|
||||||
|
https://blueprints.launchpad.net/nova/+spec/websocket-proxy-to-host-security
|
||||||
|
|
||||||
|
Currently, while the noVNC, HTML5 SPICE and serial console clients can
|
||||||
|
use TLS-encrypted WebSockets to communicate with the nova websocket proxy
|
||||||
|
server (and authenticate with Nova console tokens), the encryption and
|
||||||
|
authentication ends there. There is neither encryption or authentication
|
||||||
|
between the websockets proxy and the compute node VNC, SPICE and serial
|
||||||
|
console servers.
|
||||||
|
|
||||||
|
This spec describes the addition of TLS for all three services to provide
|
||||||
|
encryption, and use of x509 certificates to authenticate connection
|
||||||
|
attempts to the compute node console servers.
|
||||||
|
|
||||||
|
Problem description
|
||||||
|
===================
|
||||||
|
|
||||||
|
Currently, there is neither authentication or encryption between the
|
||||||
|
websocket proxy server and the compute node VNC, SPICE & serial console
|
||||||
|
servers. Were a malicious entity to gain access to the "internal"
|
||||||
|
network of an OpenStack deployment they can perform three attacks:
|
||||||
|
|
||||||
|
* Passive snooping of all traffic between the proxy and compute node.
|
||||||
|
This could allow the attacker to identify key strokes associated with
|
||||||
|
tenant user passwords, or view sensitive information displayed on
|
||||||
|
the virtual desktop.
|
||||||
|
|
||||||
|
* Actively impersonate the proxy server, making connections to the
|
||||||
|
compute node VNC, SPICE, serial console servers, viewing the tenant's
|
||||||
|
data and interacting with their machine.
|
||||||
|
|
||||||
|
* Actively impersonate the compute node, providing a spoof remote
|
||||||
|
desktop for the proxy server to connect to. This allows the attacker
|
||||||
|
to modify the information presented on the desktop for their own
|
||||||
|
purposes.
|
||||||
|
|
||||||
|
Use Cases
|
||||||
|
---------
|
||||||
|
|
||||||
|
This addresses the use case where VNC, SPICE or serial console is
|
||||||
|
enabled for a production deployment of Nova, and the Nova WebSocketProxy
|
||||||
|
is running.
|
||||||
|
|
||||||
|
The aim is to provide protection against the three attack scenarios
|
||||||
|
described above. They will be prevented as follows:
|
||||||
|
|
||||||
|
* Passive snooping of the traffic between the proxy and compute node
|
||||||
|
for VNC, SPICE and serial console will be blocked by use of TLS for
|
||||||
|
encryption of the remote desktop session data.
|
||||||
|
|
||||||
|
* Active impersonation of the proxy server will be prevented for VNC
|
||||||
|
and serial console by enabling the use of x509 certificates. The
|
||||||
|
proxy server will have to present its own certificate to the compute
|
||||||
|
node when connecting which will validate the certificate against its
|
||||||
|
permitted whitelist. At time of writing SPICE does not have support
|
||||||
|
for validating client x509 certificates. If this is developed by
|
||||||
|
the SPICE maintainers, it will also be added to Nova.
|
||||||
|
|
||||||
|
* Active impersonation of the compute node will be prevented for VNC,
|
||||||
|
SPICE and serial console through the use of x509 certificates. The
|
||||||
|
compute node will send its certificate to the proxy server, which
|
||||||
|
will then validate the certificate against the CA certificates.
|
||||||
|
|
||||||
|
This protection is based on the assumption that the attacker is not
|
||||||
|
able to get x509 certificates issued by the authority used on the
|
||||||
|
compute nodes and proxy servers.
|
||||||
|
|
||||||
|
Proposed change
|
||||||
|
===============
|
||||||
|
|
||||||
|
This blueprint would introduce callbacks into the websocket proxy classes
|
||||||
|
to enable negotiation of security features such as TLS encryption, x509
|
||||||
|
certificate validation and other authentication schemes. The hooks will
|
||||||
|
be able to optionally perform protocol specific handshakes, and then
|
||||||
|
modify the socket between the proxy and compute node, replacing the
|
||||||
|
default clear text socket with an TLS wrapped one, or equivalent.
|
||||||
|
|
||||||
|
The intention is to implemented the VeNCrypt authentication scheme for
|
||||||
|
VNC, which requires providing a security proxy hook that can perform a
|
||||||
|
basic RFB protocol handshake / negotiation.
|
||||||
|
|
||||||
|
For SPICE and serial consoles, it is sufficient to simply replace the
|
||||||
|
default clear text socket with a TLS wrapped one. It is not immediately
|
||||||
|
neccesssary to get involved in the SPICE protocol negotiation, since
|
||||||
|
TLS is enabled before the protocol even starts.
|
||||||
|
|
||||||
|
There is no impact on migration, since the change does not require any
|
||||||
|
update to the guest XML configuration. It is purely a host level config
|
||||||
|
setting on the compute nodes.
|
||||||
|
|
||||||
|
Alternatives
|
||||||
|
------------
|
||||||
|
|
||||||
|
* Doing end-to-end security: this would require supporting more advanced
|
||||||
|
encryption and authentication in the HTML5 clients. Unfortunately, this
|
||||||
|
requires doing cryptography in the browser, which is not really feasible
|
||||||
|
until more browsers start implementing the HTML5 WebCrypto API. End-to-end
|
||||||
|
security would also imply that the remote tenant client is able to directly
|
||||||
|
see the x509 certificates associated with the compute nodes. This forces
|
||||||
|
the deployer to use the same x509 certificate authority for both connections
|
||||||
|
inside the cloud and on the public internet. From a manageability point of
|
||||||
|
view it is highly desirable to have CA for the internal network completely
|
||||||
|
separate from the CA used for public tenant facing servers.
|
||||||
|
|
||||||
|
* Using a tool like stunnel: There are a couple of issues with this. The first
|
||||||
|
is that it locks us in to a particular authentication mechanism -- stunnel
|
||||||
|
works fine for TLS, but will not work if we want to use SASL instead.
|
||||||
|
The second issue is that it bypasses normal VNC security negotation, which
|
||||||
|
does the initial handshake in the clear, and then moves on to security
|
||||||
|
negotiation later. It is desired to stay within the confines of the standard
|
||||||
|
RFB (VNC) specification. The third issue is that this would sidestep the
|
||||||
|
issue of authentication -- a malicous entity could still connect directly to
|
||||||
|
the unauthenticated port, unless you explicitly set up your firewall to block
|
||||||
|
remote connections to the normal VNC ports (which requires more setup on the
|
||||||
|
part of the deployer -- we want to make it fairly easy to use this).
|
||||||
|
|
||||||
|
Data model impact
|
||||||
|
-----------------
|
||||||
|
|
||||||
|
None.
|
||||||
|
|
||||||
|
REST API impact
|
||||||
|
---------------
|
||||||
|
|
||||||
|
None.
|
||||||
|
|
||||||
|
Security impact
|
||||||
|
---------------
|
||||||
|
|
||||||
|
The actual crypto done would depend on the driver being used. It will be
|
||||||
|
important to ensure that the libraries used behind any implemented drivers
|
||||||
|
are actually secure.
|
||||||
|
|
||||||
|
Assuming the driver is secure and implements both authentication and
|
||||||
|
encryption, the security of the deployment would be strengthened.
|
||||||
|
|
||||||
|
For new deployments, all compute nodes and thus all VM will be able to have
|
||||||
|
TLS enabled straightaway. The console proxy nodes can thus mandate use of
|
||||||
|
TLS for all connections. When upgrading existing deployments, however, the
|
||||||
|
console proxy node will need to allow for some VMs / compute nodes using
|
||||||
|
non-TLS connections. During this transition period the console proxy is
|
||||||
|
thus potentially susceptible to a MITM downgrade attack where the attacker
|
||||||
|
strips TLS. This is no worse than the security risk of running all compute
|
||||||
|
nodes in plain text as is done with all existing Nova releases. It simply
|
||||||
|
means that the full security benefit is not obtained until all compute nodes
|
||||||
|
and running VMs have been upgraded to use TLS. Once this is done and the
|
||||||
|
'tls_required' config options are set to 'true', a downgrade attack is no
|
||||||
|
longer possible.
|
||||||
|
|
||||||
|
Notifications impact
|
||||||
|
--------------------
|
||||||
|
|
||||||
|
None.
|
||||||
|
|
||||||
|
Other end user impact
|
||||||
|
---------------------
|
||||||
|
|
||||||
|
None.
|
||||||
|
|
||||||
|
Performance Impact
|
||||||
|
------------------
|
||||||
|
|
||||||
|
Minimal. The extra encryption will most likely be performed via a C-based
|
||||||
|
python library, so there will be relatively low overhead.
|
||||||
|
|
||||||
|
Other deployer impact
|
||||||
|
---------------------
|
||||||
|
|
||||||
|
For VNC, a deployer will have to enable use of the 'vencrypt' authentication
|
||||||
|
scheme. This will be done via a new 'vnc.auth_schemes' configuration parameter
|
||||||
|
which takes a list of strings identifying VNC authentication schemes to try.
|
||||||
|
|
||||||
|
When the 'vencrypt' scheme is chosen, the deployer will also have to provide
|
||||||
|
x509 certificate configuration for the novncproxy service
|
||||||
|
|
||||||
|
.. code::
|
||||||
|
|
||||||
|
[vnc]
|
||||||
|
tls_ca_certs = /path/to/ca-cert-bundle.pem
|
||||||
|
tls_client_cert = /path/to/client-cert.pem
|
||||||
|
tls_client_key = /path/to/client-key.pem
|
||||||
|
|
||||||
|
In addition there will be a requirements to configure the virtualization
|
||||||
|
host to enable use of TLS with VNC. For QEMU/KVM compute nodes this will
|
||||||
|
involve modifying /etc/libvirt/qemu.conf and issuing x509 certificates to
|
||||||
|
the compute nodes. (see `References`_).
|
||||||
|
|
||||||
|
When enabling 'vencrypt' for an existing deployment, two stages will be
|
||||||
|
required. Initially the 'vnc.auth_schemes' configuration parameter will
|
||||||
|
need to list both 'vencrypt' and 'none' auth schemes. This allows the
|
||||||
|
proxy to connect to both pre-existing deployed compute hosts which do
|
||||||
|
not have TLS turned on and newly updated compute with TLS. Once all
|
||||||
|
compute hosts have been updated to enable TLS, the 'vnc.auth_schemes'
|
||||||
|
configuration parameter can be switched to only permit 'vencrypt'.
|
||||||
|
|
||||||
|
|
||||||
|
For SPICE, the deployer will also have to provide x509 certificate
|
||||||
|
configuration for the spicehtml5proxy service
|
||||||
|
|
||||||
|
.. code::
|
||||||
|
|
||||||
|
[spice]
|
||||||
|
tls_ca_certs = /path/to/ca-cert-bundle.pem
|
||||||
|
tls_required = <boolean>
|
||||||
|
|
||||||
|
Note SPICE does not currently make use of client certificates, so
|
||||||
|
there is no equivalent to the 'vnc.tls_client_cert' parameter.
|
||||||
|
|
||||||
|
In addition there will be a requirements to configure the virtualization
|
||||||
|
host to enable use of TLS with SPICE. For QEMU/KVM compute nodes this will
|
||||||
|
involve modifying /etc/libvirt/qemu.conf and issuing x509 certificates to
|
||||||
|
the compute nodes. (see `References`_).
|
||||||
|
|
||||||
|
When enabling TLS for an existing deployment, two stages will be
|
||||||
|
required. Initially the 'spice.tls_required' configuration parameter
|
||||||
|
will be set to 'False'. This allows the proxy to connect to both
|
||||||
|
pre-existing deployed compute hosts which do not have TLS turned on
|
||||||
|
and newly updated compute with TLS. Once all compute hosts have been
|
||||||
|
updated to enable TLS, the 'spice.tls_required' configuration parameter
|
||||||
|
can be switched to 'True'.
|
||||||
|
|
||||||
|
For serial consoles, a deployer will have to enable use of TLS by providing
|
||||||
|
a CA certificate bundle, and optionally a client certificate and key
|
||||||
|
|
||||||
|
.. code::
|
||||||
|
|
||||||
|
[serial_console]
|
||||||
|
tls_ca_certs = /path/to/ca-cert-bundle.pem
|
||||||
|
tls_client_cert = /path/to/client-cert.pem
|
||||||
|
tls_client_key = /path/to/client-key.pem
|
||||||
|
tls_required = <boolean>
|
||||||
|
|
||||||
|
In addition there will be a requirements to configure the virtualization
|
||||||
|
host to enable use of TLS with serial ports. For QEMU/KVM compute nodes
|
||||||
|
this will involve modifying /etc/libvirt/qemu.conf and issuing x509
|
||||||
|
certificates to the compute nodes. (see `References`_).
|
||||||
|
|
||||||
|
When enabling TLS for an existing deployment, two stages will be
|
||||||
|
required. Initially the 'serial_console.tls_required' configuration
|
||||||
|
parameter will be set to 'False'. This allows the proxy to connect to
|
||||||
|
both pre-existing deployed compute hosts which do not have TLS turned on
|
||||||
|
and newly updated compute with TLS. Once all compute hosts have been
|
||||||
|
updated to enable TLS, the 'serial_console.tls_required' configuration
|
||||||
|
parameter can be switched to 'True'.
|
||||||
|
|
||||||
|
Developer impact
|
||||||
|
----------------
|
||||||
|
|
||||||
|
None of the other non-QEMU hypervisors support VNC / SPICE / serial port
|
||||||
|
TLS encryption at this, so this work is only relevant for libvirt with
|
||||||
|
QEMU/KVM. If other hypervisors gain TLS support later, it should be
|
||||||
|
straightforward for them to enable it using the enhancements done for
|
||||||
|
libvirt with QEMU.
|
||||||
|
|
||||||
|
Implementation
|
||||||
|
==============
|
||||||
|
|
||||||
|
Assignee(s)
|
||||||
|
-----------
|
||||||
|
|
||||||
|
Primary assignee:
|
||||||
|
sfinucan
|
||||||
|
|
||||||
|
Work Items
|
||||||
|
----------
|
||||||
|
|
||||||
|
1. Modify the websockets proxy base classes to add hooks that
|
||||||
|
subclasses can use to implement encryption and authentication.
|
||||||
|
|
||||||
|
2. Create a framework for implementing VNC authentication
|
||||||
|
mechanisms.
|
||||||
|
|
||||||
|
3. Create a websockets proxy security driver that can perform
|
||||||
|
a VNC protocol negotiation, invoking the VNC authentication
|
||||||
|
schemes at appropriate times.
|
||||||
|
|
||||||
|
4. Modify the novncproxy server to enable the VNC security
|
||||||
|
driver
|
||||||
|
|
||||||
|
5. Modify the spicehtml5proxy server to enable it to open an
|
||||||
|
SSL socket when required
|
||||||
|
|
||||||
|
6. Modify devstack to enable it to generate suitable certificates
|
||||||
|
for compute nodes and security proxy nodes and enable TLS for
|
||||||
|
VNC, SPICE and serial consoles.
|
||||||
|
|
||||||
|
7. Modify tempest to perform blackbox testing of the remote
|
||||||
|
console service, to validate that its possible to successfully
|
||||||
|
establish a console connection when TLS is enabled.
|
||||||
|
|
||||||
|
8. Modify openstack-manuals content to describe the procedure
|
||||||
|
for deploying compute nodes and the console proxy servers
|
||||||
|
with TLS security enabled.
|
||||||
|
|
||||||
|
Dependencies
|
||||||
|
============
|
||||||
|
|
||||||
|
Support for the VNC and SPICE features is already available in all
|
||||||
|
versions of QEMU and Libvirt that Nova supports, and it is thus
|
||||||
|
already possible to test it with currently gate CI nodes.
|
||||||
|
|
||||||
|
Support for the serial console TLS feature will require QEMU >= 2.6
|
||||||
|
and a libvirt >= 2.2.0. Deployments which lack these versions will
|
||||||
|
have to continue using the serial console in clear text mode until
|
||||||
|
they upgrade.
|
||||||
|
|
||||||
|
Testing
|
||||||
|
=======
|
||||||
|
|
||||||
|
Tempest will be enhanced to validate the ability to open a
|
||||||
|
remote console for VNC and SPICE. It is TBD whether TLS support
|
||||||
|
for console access will be tested in existing CI gate jobs vs
|
||||||
|
adding a new gate job.
|
||||||
|
|
||||||
|
Gate testing of serial console support will not be possible with
|
||||||
|
current gate CI versions, unless it is possible to have gate jobs
|
||||||
|
with latest upstream libvirt + QEMU releases (as opposed to what
|
||||||
|
is in Ubuntu LTS).
|
||||||
|
|
||||||
|
Documentation Impact
|
||||||
|
====================
|
||||||
|
|
||||||
|
We will need to document the new configuration options, as well as how to
|
||||||
|
generate certificates for the TLS driver (See `Other deployer impact`_).
|
||||||
|
|
||||||
|
References
|
||||||
|
==========
|
||||||
|
|
||||||
|
* The most recent version of the VeNCrypt specification can be found at
|
||||||
|
https://github.com/rfbproto/rfbproto/blob/master/rfbproto.rst#id28
|
||||||
|
|
||||||
|
* SPICE TLS: http://www.spice-space.org/docs/spice_user_manual.pdf -- page 11
|
||||||
|
|
||||||
|
* libvirt TLS setup:
|
||||||
|
|
||||||
|
* VNC: http://wiki.libvirt.org/page/VNCTLSSetup,
|
||||||
|
* SPICE: http://people.freedesktop.org/~teuf/spice-doc/html/ch02s08.html
|
||||||
|
|
||||||
|
History
|
||||||
|
=======
|
||||||
|
|
||||||
|
.. list-table:: Revisions
|
||||||
|
:header-rows: 1
|
||||||
|
|
||||||
|
* - Release Name
|
||||||
|
- Description
|
||||||
|
* - Kilo
|
||||||
|
- Introduced
|
||||||
|
* - Liberty
|
||||||
|
- Re-proposed
|
||||||
|
* - Mitaka
|
||||||
|
- Re-proposed
|
||||||
|
* - Newton
|
||||||
|
- Re-proposed
|
||||||
|
* - Ocata
|
||||||
|
- Re-proposed
|
||||||
|
* - Pike
|
||||||
|
- Re-proposed
|
||||||
Loading…
Reference in New Issue
Block a user