From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:53902) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YXVAn-00038n-QP for qemu-devel@nongnu.org; Mon, 16 Mar 2015 09:35:17 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YXVAh-0006fY-MU for qemu-devel@nongnu.org; Mon, 16 Mar 2015 09:35:13 -0400 Received: from mx1.redhat.com ([209.132.183.28]:40530) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YXVAh-0006en-Hh for qemu-devel@nongnu.org; Mon, 16 Mar 2015 09:35:07 -0400 Date: Mon, 16 Mar 2015 13:35:02 +0000 From: "Daniel P. Berrange" Message-ID: <20150316133502.GL10189@redhat.com> References: <1426509364-19513-1-git-send-email-berrange@redhat.com> <1426509364-19513-4-git-send-email-berrange@redhat.com> <87ioe1axpf.fsf@linaro.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <87ioe1axpf.fsf@linaro.org> Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH 3/3] ui: fix VNC websockets TLS integration Reply-To: "Daniel P. Berrange" List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Alex =?utf-8?Q?Benn=C3=A9e?= Cc: qemu-devel@nongnu.org, Gerd Hoffmann On Mon, Mar 16, 2015 at 01:17:16PM +0000, Alex Benn=C3=A9e wrote: >=20 > Daniel P. Berrange writes: >=20 > > The way the websockets TLS code was integrated into the VNC server > > made it insecure and essentially useless. The only time that the > > websockets TLS support could be used is if the primary VNC server > > > > > With this patch applied a number of things change > > > > - TLS is not activated for websockets unless the 'tls' flag is > > actually given. > > - Non-TLS websockets connections are dropped if TLS is active > > - The client certificate is validated after handshake completes > > if the 'x509verify' flag is given > > - Separate VNC auth scheme is tracked for websockets server, > > since it makes no sense to try to use VeNCrypt over a TLS > > enabled websockets connection. > > - The separate "VncDisplayTLS ws_tls" field is dropped, since > > the auth setup ensures we can never have multiple TLS sessions. >=20 > I wonder if the mechanical changes to the tls field could be separated > from the logic changes to the handling of authentication and certificat= e > checking? They are rather intertwined, because the need for this duplicated TLS field was a result of the way auth was mishandled. So cleaning up one implies cleaning up the other & vica-verca. > > @@ -422,13 +417,6 @@ void vnc_tls_client_cleanup(struct VncState *vs) > > vs->tls.session =3D NULL; > > } > > g_free(vs->tls.dname); > > -#ifdef CONFIG_VNC_WS > > - if (vs->ws_tls.session) { > > - gnutls_deinit(vs->ws_tls.session); > > - vs->ws_tls.session =3D NULL; > > - } > > - g_free(vs->ws_tls.dname); > > -#endif /* CONFIG_VNC_WS */ >=20 > I get we have added a bunch of exit cases earlier on that clean-up but > what happens when we do a clean shutdown? Have we just leaked? We deleted the vs->ws_tls field from the struct entirely, so there's never any data to be leaked here. > Perhaps the tls.session cleanup code should be in a shared function? This is patch is a precursor to a major refactoring & cleanup of the TLS code which will reduce code duplication significantly https://github.com/berrange/qemu/commits/qemu-io-channel-4 Regards, Daniel --=20 |: http://berrange.com -o- http://www.flickr.com/photos/dberrange= / :| |: http://libvirt.org -o- http://virt-manager.or= g :| |: http://autobuild.org -o- http://search.cpan.org/~danberr= / :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vn= c :|