Unable to load NoVNC Console on Nutanix Cluster

[qwerty017]

I know this is fairly specific issue but if uBO-WebSocket is enabled I am unable to access the NoVNC Console and it just hangs with the message "noVNC ready: native WebSockets, canvas rendering".
I have tried this even with only the WebSocket extension loaded and nothing else, so no filtering with uBlock, and as soon as it is enabled the NoVNC Console stops working. I have attached the logs I was able to pull from the chrome console. If there are other logs you can use I will get them to you.

websocketlogs.zip

[gorhill]

What is "NoVNC Console"?

[qwerty017]

It is a web based VNC used by Nutanix which is kind of like VMWare. The Console allows a person to view the virtual machine directly, as if through a directly connected keyboard and monitor. http://kanaka.github.io/noVNC/noVNC/vnc.html has more info about it. The weird thing is that when I tried some of the other NoVNC setups they have listed in their wiki they all worked so if you want to see what I am seeing I can do a screen share or similar with you.

[qwerty017]

So I did some more digging into this on my side and it looks like it has to do with the CSP of the page. If I use the "Disable Content-Security-Policy" extension to tell the page to ignore the CSP then it works perfectly fine. If it helps I have attached the CSP below.

Content-Security-Policy:default-src 'self'; script-src 'self' 'unsafe-inline' 'unsafe-eval'; style-src 'self' 'unsafe-inline' 'unsafe-eval'; connect-src 'self' wss:;
X-WebKit-CSP:default-src 'self'; script-src 'self' 'unsafe-inline' 'unsafe-eval'; style-src 'self' 'unsafe-inline' 'unsafe-eval'; connect-src 'self' wss:;

For now I have just started using the above extension to disable the CSP on these pages.

[gorhill]

uBO-Websocket transposes websocket connection attempts into image requests in order to enable the webRequest API to intercept these websocket connection attempts. uBO will intercept these special image requests and redirect to an internal data:-based URI if the connection is to be accepted, or will just plainly cancel the request if the connection is to be refused. So given the CSP above, the websocket connection always fails because data: is not a whitelisted scheme in default-src.

The solution would be to use message passing instead of tricking the webRequest API -- as was suggested here.

[qwerty017]

Would it be possible to either inject the additional CSP rule or add a whitelist feature for these type of side cases?

[gorhill]

inject the additional CSP rule or add

I rather avoid relaxing existing CSP directives, I want uBO to at most make existing CSP directives stricter. The clean solution is message passing.

[qwerty017]

Ok. Makes sense to make things more secure rather than less.

On Mon, Oct 24, 2016 at 11:05 AM, Raymond Hill notifications@github.com
wrote:

inject the additional CSP rule or add

I rather avoid relaxing existing CSP directives, I want uBO to at most
make existing CSP directives stricter. The clean solution is message
passing.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
#7 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AANP-1fT0aXlHTgR4HSAMRbcTwLdgbgNks5q3PNVgaJpZM4Jvl5O
.

Life is a tragedy for those who feel, and a comedy for those who think.

[qwerty017]

Working perfectly now for my issue. Thanks.