Re: [Qemu-devel] [PATCH 3/3] ui: fix VNC websockets TLS integration

[Daniel P. Berrange]

On Tue, Mar 17, 2015 at 08:36:40AM +0100, Gerd Hoffmann wrote:
>   Hi,
> 
> >  - 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.
> 
> Hmm.  That is a problem for the QAPI, the auth scheme is linked to the
> vnc server not the socket.
> 
> What is the point in having separate auth schemes for normal sockets and
> websockets?  From a security point of view it IMHO doesn't buy you much
> to have a better auch scheme on the normal sockets as the user/client
> has the option to choose websockets ...

The problem is that the VeNCrypt auth scheme is not actally really
an auth scheme. VeNCrypt is a way to negotiate TLS session on the
VNC server, and then run one of the traditionl auth schemes over
that session. When using websockets, we cannot use VeNCrypt because
the browser websockets client can't do TLS negotigate part way
through the VNC protocol auth process. It has to have TLS on the
connection as a whole, hence the VNC websockets server will setup
TLS during the initial HTTP header phase, before the VNC protocol
even starts running.

Currently if you have VeNCrypt enabled (due to 'tls' flag to -vnc)
then the websockets server is useless because no client can connect.
The only solution to this is to not use VeNCrypt at all.

I could have just stuck with the 'auth' & 'subauth' fields in the
VncDisplay class, and translated them into something else in the
vnc_client_connect method when setting up VncState, but i figure
it was clearer to just add a 'ws_auth' field to VncDisplay
instead and avoid the translation step.

> >  - The separate "VncDisplayTLS ws_tls" field is dropped, since
> >    the auth setup ensures we can never have multiple TLS sessions.
> > 
> > This ensures that when TLS is activated for websockets, it has
> > exactly the same security characteristics as when activated for
> > the primary VNC socket.
> 
> Except for the auth scheme.

When I say they are the same, I mean from a high level security
characteristics, not the low level protocol auth codes.

 eg if you -vnc 127.0.0.1:5901,websockets=5902,tls,x509,password

Then for normal VNC server you will get

  vs->auth = VNC_AUTH_VENCRYPT
  vs->subauth = VNC_AUTH_VENCRYPT_X509VNC

This gives a TLS handshake, with x509 certificates and the VNC password
auth scheme.

And for the websockets VNC server you will get

  vs->ws_auth = VNC_AUTH_VNC

combined with https:// requirement. This gives a TLS handshake with
x509 certificates and VNC password auth scheme.

So, yes, the VNC protocol auth numbers are diferent, but the actual
security characteristics, encryption setup and auth scheme *are*
identical.

If we made the VNC auth protocol codes the same in both cases, you
would actually be making the security setup *different*, because you
would have TLS running over TLS giving double-encryption in the
websockets case. Of course you can't do that because the browser has
no way to achieve that, hence why the current QEMU impl is unusuably
broken for websockets + TLS.


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 :|