As part of the TLS everwhere work: a connection towards the VNC console should go through an encrypted channel at all times. Public TLS is already covered (from a client in the external network to HAProxy). But internal communications should be covered as well. These include: * From HAProxy to the nova-vncproxy * from the nova-vncproxy to the libvirtd instance Additional information ---------------------- Nova's VNC proxy works by using a fairly generic websocket proxy that will detect TLS traffic, and use encrypted websockets to communicate with libvirt's VNC in the compute. One would access this using an HTML5-based client called novnc. Enabling TLS in libvirt's VNC uses the VeNCrypt specification, which unfortunately is not supported by novnc [1][2]. It seems that attempting to configure TLS in the VNC and using TLS in the proxy, will result in an error in the VNC Protocol (specifically saying: "Unsupported security types: 19"), and the connection dropping. There is a blueprint explaining the issue better [3], however, it wasn't implemented. It seems that implementing this blueprint is necessary to get end-to-end encryption. [1] https://github.com/novnc/noVNC/issues/105 [2] https://github.com/novnc/noVNC/issues/342 [3] https://specs.openstack.org/openstack/nova-specs/specs/ocata/approved/websocket-proxy-to-host-security.html
Reassigning to DFG:Compute, as this needs work in noVNC.
This looks like a duplicate of an existing RFE. This has been bouncing around upstream for a few cycles now, and we hope to finally get it in in this cycle. *** This bug has been marked as a duplicate of bug 1025429 ***