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