Spice, NoVNC and TLS
Dear Openstack community, I would be happy to hear if anybody has configured Spice or noVNC console with TLS. Is this possible with using spicehtml5proxy? As far I know, it is easy to set up the TLS until the server running spiche5html(or noVNC). And according to Websockets documentation, it will only establish itself over existing http connection. How the proxy actually forms this connection? Is it possible to pass TLS certificates to it? My requirement would also be, that self-signed certificates are no-go. Best, and thanks, Jani -- Berner Fachhochschule / Bern University of Applied Sciences IT-Services / Team Linux & Infrastructure Services Jani Heikkinen IT Linux Engineer ___________________________________________________________ Dammweg 3, CH-3013 Bern Telefon direkt +41 31 848 68 14 Telefon Servicedesk +41 31 848 48 48 jani.heikkinen@bfh.ch
Which version of Nova are you running? Are we talking about TLS from the user to the proxy, from the proxy to the hypervisor, or both? TLS from the user to the proxy has been supported for a long time. The SPICE implementation added TLS support for traffic between the proxy and the hypervisor relatively recently on the hypervisor side, but I would be surprised [1] if the HTML5 proxy supported it. https://review.opendev.org/c/openstack/nova/+/922544 is the specific patch I am referring to, which landed in 2024.2. Michael 1: my reading of the proxy code is that it does not, but I look forward to being surprised by some subtleties I've missed. On Tue, Mar 18, 2025 at 2:39 AM Jani Heikkinen <jani.heikkinen@bfh.ch> wrote:
Dear Openstack community,
I would be happy to hear if anybody has configured Spice or noVNC console with TLS.
Is this possible with using spicehtml5proxy?
As far I know, it is easy to set up the TLS until the server running spiche5html(or noVNC).
And according to Websockets documentation, it will only establish itself over existing http connection.
How the proxy actually forms this connection? Is it possible to pass TLS certificates to it?
My requirement would also be, that self-signed certificates are no-go.
Best, and thanks, Jani
-- Berner Fachhochschule / Bern University of Applied Sciences IT-Services / Team Linux & Infrastructure Services Jani Heikkinen IT Linux Engineer ___________________________________________________________ Dammweg 3, CH-3013 Bern Telefon direkt +41 31 848 68 14 Telefon Servicedesk +41 31 848 48 48 jani.heikkinen@bfh.ch
On 17/03/2025 19:29, Michael Still wrote:
Which version of Nova are you running? Are we talking about TLS from the user to the proxy, from the proxy to the hypervisor, or both?
TLS from the user to the proxy has been supported for a long time. The SPICE implementation added TLS support for traffic between the proxy and the hypervisor relatively recently on the hypervisor side, but I would be surprised [1] if the HTML5 proxy supported it.
https://review.opendev.org/c/openstack/nova/+/922544 is the specific patch I am referring to, which landed in 2024.2.
the answer is basically the same for vnc tls between the client and the proxy was added a very long time ago. tls between the proxy and qemu instance as added later for vnc we use the vencypt auth scheme to to mutal tls between the proxy and the qemu instance https://opendev.org/openstack/nova/commit/7c593dc505111ac79a75f4e09a2a37485e... many installer have supproted this for 4+ years https://opendev.org/openstack/openstack-ansible-os_nova/commit/2b8d5a0b88b81...
Michael
1: my reading of the proxy code is that it does not, but I look forward to being surprised by some subtleties I've missed.
On Tue, Mar 18, 2025 at 2:39 AM Jani Heikkinen <jani.heikkinen@bfh.ch> wrote:
Dear Openstack community,
I would be happy to hear if anybody has configured Spice or noVNC console with TLS.
Is this possible with using spicehtml5proxy?
As far I know, it is easy to set up the TLS until the server running spiche5html(or noVNC).
And according to Websockets documentation, it will only establish itself over existing http connection.
How the proxy actually forms this connection? Is it possible to pass TLS certificates to it?
My requirement would also be, that self-signed certificates are no-go.
Best, and thanks, Jani
-- Berner Fachhochschule / Bern University of Applied Sciences IT-Services / Team Linux & Infrastructure Services Jani Heikkinen IT Linux Engineer ___________________________________________________________ Dammweg 3, CH-3013 Bern Telefon direkt +41 31 848 68 14 Telefon Servicedesk +41 31 848 48 48 jani.heikkinen@bfh.ch
Thanks Sean, On 3/17/25 21:13, Sean Mooney wrote:
On 17/03/2025 19:29, Michael Still wrote:
Which version of Nova are you running? Are we talking about TLS from the user to the proxy, from the proxy to the hypervisor, or both?
TLS from the user to the proxy has been supported for a long time. The SPICE implementation added TLS support for traffic between the proxy and the hypervisor relatively recently on the hypervisor side, but I would be surprised [1] if the HTML5 proxy supported it.
https://review.opendev.org/c/openstack/nova/+/922544 is the specific patch I am referring to, which landed in 2024.2.
Here, since I have installed Dalmatian, I have this patch. However, there is an issue with this. The XML for VM is generated, and I can see that tlsport option exists. But spice5html-proxy (and websockify underneath) seems to pick up the option port=5900(or whatever value it has) always and ignores tlsport altogether. Thus the TLS connection is not created.
the answer is basically the same for vnc
tls between the client and the proxy was added a very long time ago. tls between the proxy and qemu instance as added later
for vnc we use the vencypt auth scheme to to mutal tls between the proxy and the qemu instance
https://opendev.org/openstack/nova/commit/7c593dc505111ac79a75f4e09a2a37485e...
Thanks, I am aware of this, and have tested it. This works with self-signed certificates. With letsencrypt certificates it will not work, since libvirtd has hardcoded a certificate check, where it assumes under option KeyUsage option KeyEncipherment. This would require customise SSL options letsencrypt cert creation, and enforce RSA encryption on them. Best, Jani -- Berner Fachhochschule / Bern University of Applied Sciences IT-Services / Team Linux & Infrastructure Services Jani Heikkinen IT Linux Engineer ___________________________________________________________ Dammweg 3, CH-3013 Bern Telefon direkt +41 31 848 68 14 Telefon Servicedesk +41 31 848 48 48 jani.heikkinen@bfh.ch
Hi Michael On 3/17/25 20:29, Michael Still wrote:
Which version of Nova are you running? Are we talking about TLS from the user to the proxy, from the proxy to the hypervisor, or both?
We are running latest nova with Dalmatian, I think it is 30.0.0-5 From user to proxy TLS was easy to implement. Between proxy and hypervisor not so much (and still isn't set up).
TLS from the user to the proxy has been supported for a long time. The SPICE implementation added TLS support for traffic between the proxy and the hypervisor relatively recently on the hypervisor side, but I would be surprised [1] if the HTML5 proxy supported it.
https://review.opendev.org/c/openstack/nova/+/922544 is the specific patch I am referring to, which landed in 2024.2.
Michael
1: my reading of the proxy code is that it does not, but I look forward to being surprised by some subtleties I've missed.
Ok, thanks for checking out. I will also look at code in more detail. Cheers, Jani -- Berner Fachhochschule / Bern University of Applied Sciences IT-Services / Team Linux & Infrastructure Services Jani Heikkinen IT Linux Engineer ___________________________________________________________ Dammweg 3, CH-3013 Bern Telefon direkt +41 31 848 68 14 Telefon Servicedesk +41 31 848 48 48 jani.heikkinen@bfh.ch
I dont know if You seen this https://docs.openstack.org/nova/latest/admin/remote-console-access.html check also [console] # Adds list of allowed origins to the console websocket proxy to allow # connections from other origin hostnames. # Websocket proxy matches the host header with the origin header to # prevent cross-site requests. This list specifies if any there are # values other than host are allowed in the origin header. For more information, # refer to the documentation. (list value) #allowed_origins =
participants (4)
-
Jani Heikkinen
-
Michael Still
-
przemyslaw.kuczynski＠ochk.pl
-
Sean Mooney