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

["Daniel P. Berrange" <berrange@redhat.com>]

On Tue, Mar 17, 2015 at 11:50:46AM +0100, Gerd Hoffmann wrote:
>   Hi,
> 
> > 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.
> 
> Understood.
> 
> > 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.
> 
> > 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.
> 
> Ok, so there basically is a fixed mapping from auth+subauth to ws_auth
> +ws_tls, correct?

Yes, that's correct.

> I think we should have a function setting ws_auth+ws_tls that way then,
> to make clear how this works, with a comment explaining things (which
> you can probably largely cut+paste from your mail ;)

Ok, I'll separate the code into a standalone function and try to split
this change up a bit more so it only does one thing at a time.

> > So, yes, the VNC protocol auth numbers are diferent, but the actual
> > security characteristics, encryption setup and auth scheme *are*
> > identical.
> 
> I guess we can live with the current QAPI schema then?

I thing thats probably the simplest - fwiw, libvirt won't use any extra
info even if we provided it & we can always add it later if required.

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