Blueprint for Websockify security proxy framework
This blueprint proposes a generic framework for supporting man-in-the-middle authentication and encryption between Websockify and the hypervisor graphics servers. It also proposes a reference driver for that framework for TLS security. Spec for blueprint websocket-proxy-to-host-security Change-Id: I23c5a43788afcb705b0d879cf5df4b49f0aa7a67 Previously-approved: juno
This commit is contained in:
Solly Ross
parent
f4bdca7658
commit
118e949c06
244
specs/kilo/approved/websocket-proxy-to-host-security.rst
Normal file
244
specs/kilo/approved/websocket-proxy-to-host-security.rst
Normal file
@ -0,0 +1,244 @@
|
||||
..
|
||||
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 and HTML5 SPICE clients can use TLS-encrypted
|
||||
WebSockets to communicate with Websockify (and authenticate with Nova console
|
||||
tokens), the encryption and authentication ends there. There are neither
|
||||
encryption nor authentication between Websockify and the hypervisors'
|
||||
VNC and SPICE servers.
|
||||
|
||||
This blueprint would propose introducing a generic framework for supporting
|
||||
proxying security for Websockify to use between itself and the compute nodes.
|
||||
|
||||
Problem description
|
||||
===================
|
||||
|
||||
Currently, there are neither authentication nor encryption between Websockify
|
||||
and the hypervisors' SPICE and VNC servers. Were a malicious entity to gain
|
||||
access to the "internal" network of an OpenStack deployment he or she could:
|
||||
|
||||
* "Listen" to VNC and SPICE traffic (lack of encryption)
|
||||
|
||||
* Connect freely to the SPICE and VNC servers of VMs (lack of authentication)
|
||||
|
||||
Use Cases
|
||||
---------
|
||||
|
||||
This addresses the use case where VNC or SPICE is enabled for a production
|
||||
deployment of Nova, and the Nova WebSocketProxy is running.
|
||||
|
||||
For example, suppose Alice is a normal user of an OpenStack deployment, and
|
||||
Carol is a intruder who wishes to view or access Alice's VMs. Let's suppose
|
||||
that Carol has gained access in some way to the internal network
|
||||
of an OpenStack deployment.
|
||||
|
||||
Now suppose that Alice starts a VM, which gets placed on "hypervisor-a".
|
||||
|
||||
Without this blueprint, Carol could then use Wireshark or the like to watch
|
||||
what Alice is doing with her VM's console. Furthermore, Carol could point her
|
||||
VNC client at "hypervisor-a:5900" and actually access the VM's console.
|
||||
|
||||
With this blueprint, Carol would be unable to view the VNC or SPICE traffic
|
||||
(since it would we encrypted) and would be unable to connect to the VM's
|
||||
console with her own VNC client (since it would require authentication).
|
||||
|
||||
Project Priority
|
||||
----------------
|
||||
|
||||
This does not fall under any of the specific priorities for Kilo for Nova.
|
||||
|
||||
However, it does fall under the general push to make OpenStack more secure.
|
||||
|
||||
|
||||
Proposed change
|
||||
===============
|
||||
|
||||
This blueprint would introduce a generic framework performing proxying of
|
||||
authentication and encryption. When establishing a connection, the proxy would
|
||||
act as a client to the server and a server to the client, performing different
|
||||
steps for each during the security negotiation phase of the respective
|
||||
protocols.
|
||||
|
||||
The proxy would then wrap the server socket in an encryption layer that
|
||||
respected the standard python socket class (much like python's :code:`ssl`
|
||||
library does) and pass the resulting wrapped socket off to the normal proxy
|
||||
code.
|
||||
|
||||
Authentication drivers would have a class for SPICE as well as for VNC
|
||||
(since VNC has to do some extra negotiation as part of the RFB protocol).
|
||||
Deployers could then point Nova to the appropriate driver and options via
|
||||
configuration options.
|
||||
|
||||
A base driver for TLS [1]_ (VeNCrypt for VNC, plain TLS for SPICE) would be
|
||||
included as an example implementation, although it would be beneficial to
|
||||
develop further drivers, such as a SASL driver [2]_.
|
||||
|
||||
.. [1] To ensure only the correct clients connect, the proxy would send
|
||||
the hypervisor x509 client certificates, and the server would reject
|
||||
any certificates not signed by the specified CA (authentication). To
|
||||
prevent evesdroppers, the actual data stream would use TLS encryption.
|
||||
|
||||
.. [2] Such a driver would most likely use the GSSAPI mechanism, which would
|
||||
provide Kerberos encryption and authentication for the connections.
|
||||
However, SASL supports other mechanisms, so non-GSSAPI drivers could
|
||||
be written. Some mechanisms do not support encryption ("data-layer
|
||||
security" in SASL terms), so TLS should be used to provide encryption
|
||||
with those. SASL connections are by both SPICE and VNC on QEMU fully.
|
||||
|
||||
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.
|
||||
|
||||
* 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.
|
||||
|
||||
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
|
||||
---------------------
|
||||
|
||||
First, a deployer would have to choose the driver that he or she wished to use:
|
||||
:code:`console_proxy_security_driver = driver_name`. Then, the particular
|
||||
driver would be have configuration options under its own section in the
|
||||
configuration file. For instance, the x509/TLS driver would appear as the
|
||||
following:
|
||||
|
||||
.. code::
|
||||
|
||||
[console_proxy_tls]
|
||||
ca_certificate = /path/to/ca.cert
|
||||
client_certificate = /path/to/client.cert
|
||||
|
||||
Finally, most drivers will require extra setup outside of Nova. For instance,
|
||||
the x509/TLS driver will reqiure generating CA, client, and server
|
||||
certificates, distributing the CA and client certificates, and configuring
|
||||
libvirt to require x509/TLS encryption and authentication when connecting to
|
||||
VNC and SPICE consoles (see `References`_).
|
||||
|
||||
Developer impact
|
||||
----------------
|
||||
|
||||
None.
|
||||
|
||||
Implementation
|
||||
==============
|
||||
|
||||
Assignee(s)
|
||||
-----------
|
||||
|
||||
Primary assignee:
|
||||
sross-7
|
||||
|
||||
Other contributors:
|
||||
None
|
||||
|
||||
Work Items
|
||||
----------
|
||||
|
||||
1. Implement the base framework for proxying authentication and
|
||||
encryption.
|
||||
|
||||
2. Implement the No-op driver for VNC
|
||||
|
||||
3. Implement the basic x509/TLS driver for VNC
|
||||
|
||||
4. Implement the No-op driver for SPICE
|
||||
|
||||
5. Implement the basic x509/TLS driver for SPICE
|
||||
|
||||
|
||||
Dependencies
|
||||
============
|
||||
|
||||
While individual drivers might introduce new dependencies (e.g. a GSSAPI
|
||||
library for SASL/GSSAPI), the actual framework would not. Additionally,
|
||||
the driver proposed in this spec (the TLS driver) would use the Python
|
||||
standard library's SSL module, so no external dependencies would
|
||||
be needed.
|
||||
|
||||
|
||||
Testing
|
||||
=======
|
||||
|
||||
We should test that the framework is callable correctly. Additionally,
|
||||
we should implement logic in devstack to generate the requisite
|
||||
certificates, place them in the correct places, and configure libvirt
|
||||
correctly for the TLS driver. The TLS driver should be enabled by
|
||||
default on Nova so that our standard testing of noVNC will cover
|
||||
this.
|
||||
|
||||
|
||||
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
|
||||
Loading…
Reference in New Issue
Block a user