7.5 KiB
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)
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.
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 TLS1 (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 driver2.
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:
-
sross-7
- Other contributors:
-
None
Work Items
- Implement the base framework for proxying authentication and encryption.
- Implement a No-op driver
- Implement the basic x509/TLS driver
Dependencies
While individual drivers might introduce new dependencies, the actual framework would not.
Testing
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).
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 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
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. While both of these are supported for VNC by QEMU (and thus KVM, Xen, etc), it would appear that SPICE only supports the encryption. If a deployment is using SPICE, another driver should be used.↩︎
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.↩︎