[libvirt] libvirt tls vnc

[Radek Hladik]

Michael Kress napsal(a):
> IT WORKS!
> 
> Radek Hladik wrote:
>> Michael Kress napsal(a):
>>>>> 2009.02.26 19:09:44 LOG3[14644:3086588128 <http://www.snapanumber.com/>]: error stack: 140B3009 :
>>>>> error:140B3009:SSL routines:SSL_CTX_use_RSAPrivateKey_file:PEM lib
>>>>> 2009.02.26 19:09:44 LOG3[14644:3086588128 <http://www.snapanumber.com/>]:
>>>>> SSL_CTX_use_RSAPrivateKey_file: 906D06C: error:0906D06C:PEM
>>>>> routines:PEM_read_bio:no start line
>>>>> vncviewer: VNC server closed connection
> 
> the above error is gone now.
> 
> 
>> Stunnel can not find private key. It tries to locate it in
>> client-cert.pem (I do not know why). Either change this in
>> configuration   or appen client-key.pem to client-cert.pem. The PEM
>> file can contain both certificate and private key and stunnel will
>> handle it.
> 
> I did this now, i.e. I merged the client certificate and the private key
> into one file called client-cert.pem, first the cert, then the key.
> 
> What I still had to do:
> Check the (advanced) option "Server uses VeNCrypt SSL encryption",
> because without it I got the following error:
> "SSL_Connect: 1204F10B: error:1408F10B:SSL
> routines:SSL3_GET_RECORD:wrong version number"
> 
> It works by executing these steps :
> 1) ./ssvnc -cacert cacert.pem -mycert client-cert.pem -ssl localhost:0
> 2) See the session fail
> 3) Check "Server uses VeNCrypt SSL encryption"
> 4) Reconnect
> 
> As soon as I stay here, it's ok, but when I close ssvnc, the above
> setting won't get saved.
> 
> My questions:
> 1) Isn't there a more comfortable end user compatible method to connect
> to the beast?
> (Because with this method, users obviously are urged to have Linux on
> the client side. Or would the purchase of real vnc enterprise edition
> would be the solution there?)
> 2) I simulated an interested user owning a certificate and walked
> through the different screens of the host (before, I created a few). I
> could easily access them by just chosing to connect to "localhost:0"
> "localhost:1" ... (given the requirement to have an ssh tunnel which the
> client machine easily can build)
> Is it possible to let him only view what he's supposed to? How?
> 3) Is there a way to stick one certificate to one virtual machine?
> e.g. stick client-cert-user001.pem to /etc/libvirt-bin/qemu/user001-vm01.xml
> (trying to find a solution to question 2) with this question).
> 
> Thanks very much for your help so far, I really appreciate it!
> Kind Regards
> Michael
> 
> 

O.K. I think we are mixing a few things here altogether.
The scenario I mentioned involves ssvnc as a client (linux or windows) 
connecting via SSL/TLS to a stunnel on the beast and this stunnel 
connecting to localhost-only-listening VNC server without encryption 
itself. It looks like ssvnc can store a profiles and run with such a 
profile from a script so it should be easy to provide script that runs 
it (although I haven't tested it yet). I did test this scenario and it 
works and on the client side (windows) it was rather user friendly.
The drawback of this is an identification of the connecting client, you 
may end up with creating CA for every VM or with some certificate common 
name filtering. Stunnel can verify client's certificate against given CA 
certificate so it is definetly doable. And you can set VNC password, 
which should be sufficient as the valid certificate is needed for the 
brute force attack on the password.
The other option is to use SSH for tunneling and connecting to the 
localhost-only-listening VNC server without encryption itself. Its 
almost the same as in the previous case only you do not use X509 
certificates but SSH keys. And you do not limit your users by CA issuing 
the certificate but the user and key they are using. You can specify 
allowed port-forwards (ssh tunnels) in authorized_keys file on the 
server. On the other hand you need to create user for such logins.
If you would like to have the VeNCrypt function, I think you need ssvnc 
running on linux. However I do not know about the commercial VNC 
clients. And I think that the two previous scenarios are more flexible.

The stunnel config used is:

client = no
cert = stunnel.pem

[vnc]
accept = 5901
connect = 5905

and I've made the stunnel.pem with (on Fedora 10)
#cd /etc/pki/tls/certs
#make stunnel.pem

The VM is configured to listen on 5905 bound to localhost without any 
encryption. You can disable any incoming connections in firewall just to 
be sure...

On the windows client I run ssvnc, using SSL/TLS connecting to port 
5901. Prior a connection I've fetched the certificate and stored it as 
trusted.

Radek