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? 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 ;) > 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? cheers, Gerd
