nova-specs/specs/newton/approved/websocket-proxy-to-host-security.rst

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).

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 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¹ (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².

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: 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:

[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:

berrange

Other contributors:

sross-7

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

• Previous approvals Kilo: https://review.openstack.org/#/c/126958/ Juno: https://review.openstack.org/#/c/86422/
• 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

---

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.↩︎