Support Proxying of Encryption and Authentication in WebSocketProxy¶
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.
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)
For example, suppose Alice starts a VM, which gets placed on “hypervisor-a”. 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.
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
library does) and pass the resulting wrapped socket off to the normal proxy
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 .
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¶
REST API 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.
Other end user 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
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).
- Primary assignee:
- Other contributors:
Implement the base framework for proxying authentication and encryption.
Implement a No-op driver
Implement the basic x509/TLS driver
While individual drivers might introduce new dependencies, the actual framework would not.
We should test that the framework is callable correctly. Additionally, it will be necessary to work with infra to ensure that we can test the actual drivers (for instance, for x509/TLS, we will need to generate certificates, etc).
We will need to document the new configuration options, as well as how to generate certificates for the TLS driver (See Other deployer impact).
The most recent version of the VeNCrypt specification can be found in this thread http://sourceforge.net/p/tigervnc/mailman/message/25748057/ – http://sourceforge.net/p/tigervnc/mailman/attachment/20100720083109.GA3303%40evileye.atkac.brq.redhat.com/1/
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