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

[Alexandre DERUMIER]

>>Can't we use the same code as for VNC (assemble_vnc_ticket)? 
Yes, that was the idea


>>I am quite sure we want an AnyEvent based implementation (pveproxy)? Or why 
>>do you want to implement another, totally different server? 

Yes, I would like to reuse pveproxy.  (I just have tested HTTP::PROXY to see how it's work)

The only thing is that spice client only do proxy through http and not https.
But it should be possible to add a new listen port to pveproxy on http, only accepting CONNECT request.
Should not be a security problem if we crypt the host header, and the connection to spice use tls.


I think the main problem in HTTP::PROXY, it that the tunnel is not bi-directionnal. I have debug it, it's waiting for read spice socket.

The implementation is pretty simple:

CLIENT ---> HTTP CONNECT host:port
SERVER ----> HTTP/1.0 200 OK
            then bi-directionnal tunnel read-write 


But I don't known how to implement the bi-directionnal tunnel in perl.


(and if we use domain socket , I think it should be easy to open the socat tunnel just after the 200 response,and close it after client disconnect)



----- Mail original ----- 

De: "Dietmar Maurer" <dietmar at proxmox.com> 
À: "Alexandre DERUMIER" <aderumier at odiso.com>, pve-devel at pve.proxmox.com 
Envoyé: Lundi 17 Juin 2013 06:16:07 
Objet: RE: [pve-devel] idea for implementation of a spice http connect proxy, with pve authentification 

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