10:41 p.m.
on 2014/05/04 23:14, Aline Manera wrote:
On 05/04/2014 04:21 AM, Zhou Zheng Sheng 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
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?
> 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=XX...
>
> 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(a)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
--
Zhou Zheng Sheng / 周征晟
E-mail: zhshzhou(a)linux.vnet.ibm.com
Telephone: 86-10-82454397