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

[Dietmar Maurer]

> 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.

Can't we use the same code as for VNC (assemble_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 am quite sure we want an AnyEvent based implementation (pveproxy)? Or why
do you want to implement another, totally different server?

> 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

This is what we do with VNC
> 
> 
> or
> 
> client----->proxy--------->tcp:target node
> 
> (with iptables to block guests spice ports from outside world)

This is easier, but handling iptables is a mess.