All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Daniel P. Berrange" <berrange@redhat.com>
To: "Alex Bennée" <alex.bennee@linaro.org>
Cc: qemu-devel@nongnu.org, Gerd Hoffmann <kraxel@redhat.com>
Subject: Re: [Qemu-devel] [PATCH 3/3] ui: fix VNC websockets TLS integration
Date: Mon, 16 Mar 2015 13:35:02 +0000	[thread overview]
Message-ID: <20150316133502.GL10189@redhat.com> (raw)
In-Reply-To: <87ioe1axpf.fsf@linaro.org>

On Mon, Mar 16, 2015 at 01:17:16PM +0000, Alex Bennée wrote:
> 
> Daniel P. Berrange <berrange@redhat.com> writes:
> 
> > 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
> <snip>
> >
> > 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.
> 
> I wonder if the mechanical changes to the tls field could be separated
> from the logic changes to the handling of authentication and certificate
> 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 = 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 = NULL;
> > -    }
> > -    g_free(vs->ws_tls.dname);
> > -#endif /* CONFIG_VNC_WS */
> 
> 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
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|

  reply	other threads:[~2015-03-16 13:35 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-03-16 12:36 [Qemu-devel] [PATCH 0/3] Misc fixes for VNC Daniel P. Berrange
2015-03-16 12:36 ` [Qemu-devel] [PATCH 1/3] ui: remove unused 'wiremode' variable in VncState struct Daniel P. Berrange
2015-03-16 13:03   ` Alex Bennée
2015-03-16 12:36 ` [Qemu-devel] [PATCH 2/3] ui: replace printf() calls with VNC_DEBUG Daniel P. Berrange
2015-03-16 13:06   ` Alex Bennée
2015-03-16 12:36 ` [Qemu-devel] [PATCH 3/3] ui: fix VNC websockets TLS integration Daniel P. Berrange
2015-03-16 13:17   ` Alex Bennée
2015-03-16 13:35     ` Daniel P. Berrange [this message]
2015-03-17 10:59       ` Daniel P. Berrange
2015-03-17  7:36   ` Gerd Hoffmann
2015-03-17 10:20     ` Daniel P. Berrange
2015-03-17 10:50       ` Gerd Hoffmann
2015-03-17 10:58         ` Daniel P. Berrange
2015-03-17 10:33     ` Daniel P. Berrange
2015-03-17 10:54       ` Gerd Hoffmann

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20150316133502.GL10189@redhat.com \
    --to=berrange@redhat.com \
    --cc=alex.bennee@linaro.org \
    --cc=kraxel@redhat.com \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.