From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:35747) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UQZq5-000640-Lg for qemu-devel@nongnu.org; Fri, 12 Apr 2013 05:00:11 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UQZq0-0003sN-No for qemu-devel@nongnu.org; Fri, 12 Apr 2013 05:00:09 -0400 Received: from cantor2.suse.de ([195.135.220.15]:58911 helo=mx2.suse.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UQZq0-0003oh-F6 for qemu-devel@nongnu.org; Fri, 12 Apr 2013 05:00:04 -0400 Received: from relay1.suse.de (unknown [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id A45D5A5077 for ; Fri, 12 Apr 2013 11:00:03 +0200 (CEST) Message-ID: <5167CD18.20706@suse.de> Date: Fri, 12 Apr 2013 11:00:08 +0200 From: Tim Hardeck MIME-Version: 1.0 References: <5166BB9F.6060407@suse.de> In-Reply-To: <5166BB9F.6060407@suse.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] VNC Websocket TLS support design decisions List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel 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=20 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=3D1". > 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=20 enforced then which is not supported by noVNC. In general VNC TLS is decrypted before the Websocket decoding so it=20 can't be stacked atm. I don't think that it is needed anyway since there=20 is Websocket TLS support now but there might be HTML 5 clients with=20 VEncrypt support in the future. I haven't added any option to only allow encrypted Websockets=20 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=3D1 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=3D1" is specified noVNC shows the message that this security type= =20 is not supported which should be fine I suppose. > For my implementation I am using many parts of vnc-tls. I am planning t= o > make some functions in vnc-tls more flexible or add some checks to allo= w > 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=20 handshake which I imported from vnc-auth-vencrypt.c. Regards Tim --=20 SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix=20 Imend=F6rffer, HRB 16746 (AG N=FCrnberg) Maxfeldstr. 5, 90409 N=FCrnberg, Germany T: +49 (0) 911 74053-0 F: +49 (0) 911 74053-483 http://www.suse.de/