On 05/05/2014 12:41 AM, Zhou Zheng Sheng wrote:
on 2014/05/04 23:14, Aline Manera wrote:
This is a nice idea. I tested the vnc part. A problem in previous "[v3] Enable encryption in vm VNC console connection" is that vnc_auto.html is not protected by kimchi authentication, and this patch fixes the problem. The reason why I did not implement authentication is that the port 64667 for the VNC websocket traffic itself is not protected by Kimchi authentication. Even with this patch series, one can just git clone the noVNC official git repo, then open the following link in Opera (or Chrome?).
file:///home/edward/src/noVNC/vnc_auto.html?port=64667&host=X.X.X.X&path=?token=NAME_OF_THE_VM&encrypt=1
Then you get the guest VNC console without logging in to Kimchi. So this patch does not improve anything compared to "[v3] Enable encryption in vm VNC console connection", and it involves another redirection which makes the process a bit more complicated. I need to disagree with you. With this patch the noVNC is protected from Kimchi perspective (different from the previous patch), ie, if the user wants to get the console, he does need to get it from noVNC
On 05/04/2014 04:21 AM, Zhou Zheng Sheng wrote: source code as you described above but it will not be possible through Kimchi.
Even with the password parameter you mentioned below, if the user has the full URL (including the password) he will be able to get the console from noVNC source code without authentication.
To the password parameter works, we need to set a random password for each VNC connection with expiration time (to reset it after connection is stabilized)
So vm_connect() create a random VNC password with expiration time for 10s (just the enough time to open connection to noVNC)
That way we ensure each connection has a single valid password and if someone gets the full URL it won't be valid anymore.
We need to verify how much work is needed to implement this "password with expiration time" approach. Any help is welcome!
Had a little chat with Aline, and we have discussed two options.
(1) Poxying Websocket Request JS websocket request -> nginx -> Kimchi (CherryPy) -> websockify In this way Kimchi stays in the path so it gets the chance to auth the request before the protocol upgrade. However transparent websocket reverse proxing is just a new nginx feature, and it might not work with CherryPy. The mechanism is also too complex.
(2) Permanent Password Firstly we generate a random password and set it for the VM console (Spice/VNC). When the user wants to visit the console, the user will be firstly led to vms/vm_name/console and the handler firstly puts the password in the cookie, and raise an HTTP redirection to a fake "vnc_auto.html" served by websockify (HTTPs port 64667), so the user gets the chance to accept websockify server cert.
Then the JS scripts in the fake "vnc_auto.html" redirects the user to the real "vnc_auto.html" served by Kimchi. At last the JS in the real "vnc_auto.html" gets the password from the cookie, and uses the password to connect to Spice/VNC via websockify.
The real "vnc_auto.html" has to be served by Kimchi so that the JS in "vnc_auto.html" can get the cookies previously set by Kimchi.
We should also have a "Show Console Password" button in the front-end, so the user can get the password and the user can use other tools to connect to VNC/Spice.
(3) Temporary Password for Each New Console Session It works like option 2 but the a new password is generated and set each time in the "vms/vm_name/console" handler. We can alternatively provide a POST action on "vms/vm_name/set_ticket" to enable the JS set a temporary console password.
Our plan is to implement option 2 firstly, if we have time, implement option 3. For VMs created outside of Kimchi, we shall still re-use option 2 but just without a password. A problem here is how do we distinguish VM managed by Kimchi and VM managed by other tools. Shall we use the meta data feature, Shao He?
For option 2, I sent a V2 of "Enable Kimchi authentication in console pages" (which also fix a bug in spice support) After getting it merged, we can work in the password part independently.
I think instead of protecting vnc_auto.html, which is purely static content and not useful to protect, we should protect the VNC payload with password. Kimchi should start the VM with a random VNC password, when the user clicks the VNC link, it should links to
https://server:64667/vnc_auto.html?password=XXX&port=XXX&token=XXX&encrypt=1&path=?
Since the password is random generated, and the traffic encrypted on HTTPs, it's actually secure.
We can also improve the security by generating a new random password every time the user opens a new VNC session.
on 2014/05/02 08:49, Aline Manera wrote:
From: Aline Manera <alinefm@br.ibm.com>
As I commented in mailing list ([v3] Enable encryption in vm VNC console connection) to enable Kimchi authentication in console pages those need to be provided by Kimchi server instead of websockify web server.
I reverted the "Enable encryption in vm VNC console connection" commit, applied "[PATCH v2] Enable encryption in vm console connection" path send by Mark and make the changes needed to redirect user from websockify web server to Kimchi. So noVNC page continues to be rendered by Kimchi.
With all that done, I was able to enable authentication to vnc_auto.html and spice.html
Aline Manera (5): Revert "Enable encryption in vm VNC console connection" Make use of the mini Web server in the websockify Enable Kimchi authentication in console pages backend: Redirect 401 error to default page UI: Redirect user to console page after logging
Mark Wu (1): Enable encryption in vm console connection