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