[pve-devel] idea for implementation of a spice http connect proxy, with pve authentification

[Alexandre DERUMIER]

Hi,
I'm working again on spice, I have an idea to implement authentification.


a spice client config file is like that:

[virt-viewer]
type=spice
proxy=kvmtest1.odiso.net:3128
host=localhost
tls-port=60000
password=tempticketpassword


password field is limited to 60 characters (client side), so it's too short to crypt with rsa username,password,etc...

what we can do

[virt-viewer]
type=spice
proxy=kvmtest1.odiso.net:3128
host=rsa(base64(localhost:$plain:$username:$path))
tls-port=60000
password=tempticketpassword


So, the proxy can decode the host field, to verify authentification of the user, like for vnc ticket.


Now, I have tried with cpan HTTP::Proxy, which implemented the HTTP CONNECT method.
The problem is that it don't work with spice, because spice is doing 4 connections (after the http connect).
Spice use a different connection for main,display,inputs,mouse,....
And HTTP::Proxy use fork, from cpan doc:
"An important thing to note is that the proxy is (except when running the NoFork engine) a forking proxy: it doesn't support passing information between child processes, and you can count on reliable information passing only during a single HTTP connection (request + response)."

So only the first connection to main spice channel is made, and after that the client hang.

I don't known if it's possible to resolve that in HTTP::Proxy ?


I have find a working small http connect proxy written in python here:
https://gist.github.com/fmoo/2068759

So I don't known if we can use this ? (with authentification verification through pve webservices)





Other thing, about guests spice listen on unix domain socket.

Currently I get it work with a small qemu patch + using socat to forward to tcp. (nc don't work because of multiple spice connections).

This works without tls,  but for tls, it'll require a small patch on libspice server side. (I'll try to look at this this week)

(Note that tls works fine on tcp + proxmox certificates).


So I don't known if we want something complex with guest listen on domain sockets like

client---->proxy---->tcp:localhost:socat--->ssh---> unix:target node


or 

client----->proxy--------->tcp:target node 

(with iptables to block guests spice ports from outside world)