qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] VNC Websocket TLS support design decisions


From: Tim Hardeck
Subject: Re: [Qemu-devel] VNC Websocket TLS support design decisions
Date: Fri, 12 Apr 2013 11:00:08 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130329 Thunderbird/17.0.5

Hi,

I have sent in my current implementation some minutes ago.

On 04/11/2013 03:33 PM, Tim Hardeck wrote:

Websockets over TLS need certificates.
We already have the "x509" vnc parameter for VNC-TLS to provide the
certificates but user might have one webserver certificate and one for
VNC TLS authentication. Of course in this case they could use two vnc
instances.
The other issue is that Websockets TLS should work when vnc-tls is
disabled since GnuTLS is already a requirement for Websockets anyway.
Should I use this x509 certificate parameter also or add an additional
parameter like "ws_x509"?
In my current implementation the general "x509" vnc parameter is used to provide the path for the certificates.

Should there be an option to only allow Websockets over TLS?
For example how to react in case of the option "tls=1".
In my current implementation the Websocket connection is checked during
initiation for an encryption handshake and and then acted accordingly.
If "tls" is specified Websockets can't be used because VEncrypt is enforced then which is not supported by noVNC.

In general VNC TLS is decrypted before the Websocket decoding so it can't be stacked atm. I don't think that it is needed anyway since there is Websocket TLS support now but there might be HTML 5 clients with VEncrypt support in the future.

I haven't added any option to only allow encrypted Websockets connections [yet]. Let me know if this is worth adding another VNC option.


To my knowledge current HTML5 VNC clients do not support another
authentication then password, so no VEncrypt.
This means that if I enable tls=1 Websockets connection can't be
established for this vnc instance.
Should I add some workaround to use password authentication for
Websockets or just document it so users could use two vnc instances for
this use case?
If "tls=1" is specified noVNC shows the message that this security type is not supported which should be fine I suppose.

For my implementation I am using many parts of vnc-tls. I am planning to
make some functions in vnc-tls more flexible or add some checks to allow
them to be used for Websocket TLS connections.
Would this be OK or do you have other suggestions.
I got rid of all duplicates except of the functions regarding the TLS handshake which I imported from vnc-auth-vencrypt.c.

Regards
Tim

--
SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg)
Maxfeldstr. 5, 90409 Nürnberg, Germany
T: +49 (0) 911 74053-0  F: +49 (0) 911 74053-483
http://www.suse.de/



reply via email to

[Prev in Thread] Current Thread [Next in Thread]