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

Alexandre DERUMIER aderumier at odiso.com
Tue Jun 18 08:13:21 CEST 2013


Hi,
I have try to reproduce the bi-directionnel tunnel like run_vnc_proxy(), but it doesn't work :(

But the good news, is that I have succefully made a nodejs proxy, reimplementing verify_vnc_method (with rsa verify,ticket age verification,...).


it's working like this:

- call PVE::Qemu::spiceproxy api
       -generate a socat tunnel (randomunixsocket -> qemu spice socket)
       -return a spice_assemble_ticket
       

ticket
-------
[virt-viewer]
type=spice
proxy=proxy:3128
host=base32(vnc_assemble_ticket)      #base32 needed because spice client lowercase the string
port=randomunixsocket



client----->proxy:3128---->randomunixsocket--->socat (ssh for remote)--->qemu spice.socket.


So only 1 port is needed outside, and we have the socat for more security.

Things to do:
 - add support for spice tls for unix socket. (need to hack spicelib server side)
 - find a way to add a connect timeout to socat. (If the client don't connect, the socat tunnel is running indefinitely)
 - implemented the proxy in perl. (But maybe you are better than me for this ;)


I'll try to send patches for the end of the week.

Alexandre



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

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

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

Maybe it is better to use an dynamic port and run a separate server (like we do for VNC)? 

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

see run_vnc_proxy() in 'qm' 



More information about the pve-devel mailing list