2

Not sure if i'm really up-to-date, but i'm looking in a way to convert my existing project to use HTML5 websockets.

Here's my situation : 

- Client runs a modified java vnc applet with extra parameter (CONNECT).

- Modified stunnel listenin on webserver (with both public, private IP) port 443

- Client connects to 443 and sends (prior to RFB) a HTTP packet like :
  'CONNECT 10.0.0.1:4001'

- Stunnel opens a new stream to 10.0.0.1:4001 using SSL wrapper

- VNC Server (@10.0.0.1:4001) responds, connection is established.

Now I want to get rid of the Java Applet and switch to Websocket using NoVNC.

I want to be able to : 

- Open a single port on the webserver (HTTPS preferably)
- Have client connect using HTML5 only (no more java applet)

I cannot change : 

- VNCServer will still be listening on private LAN only.
- VNCServer will still listen to a bunch of ports, each corresponding to
  a virtual server

Questions are : 

- How to give NoVNC the notion of target HOST:PORT ?
- Is stunnel still be usable ? Or should I change to websocket proxy ?

If anyone has a starting point, i'd really appreciate !

Disco
  • 4,226
  • 11
  • 58
  • 76

1 Answers1

5

Disclaimer: I created noVNC so my answer may be heavily biased ;-)

I'll answer you second question first:

stunnel cannot be used directly by noVNC. The issue is that the WebSockets protocol has an HTTP-like initial handshake and the messages are framed. In addition, until binary payload support is added to WebSockets, the payload is base64 encoded by the websockets proxy (websockify). Adding the necessary support to stunnel would be non-trivial but certainly doable. In fact noVNC issue #37 is an aspirational feature to add this support to stunnel.

First question:

noVNC already has a concept of HOST:PORT via the RFB.connect(host, port, password) method. The file vnc_auto.html at the top level shows how to get noVNC to automatically connect on page load based on the host, port and password specified as URL query string parameters.

However, I think what you are really asking is how do you get noVNC to connect to alternate VNC server ports on the backend. This problem is not directly addressed by noVNC and websockify. There are several ways to solve this and it usually involves an out-of-band setup/authorization mechanism so that the proxy can't be used to launch attacks by arbitrary hosts. For example, at my company we have a web based management framework that integrates noVNC and when the user wants to connect to the console, an authenticated AJAX call is used to configure the proxy for that particular user and the system they want to connect to. Our web management interface is internal only.

Ganeti Web Manager uses a similar model and the source is available. They have a fork of VNCAuthProxy that has WebSockets support. They use a control channel from the web interface to the VNCAuthProxy to setup a temporary password associated with a specific VNC server host:port.

Also OpenStack (Nova) integrates noVNC uses a similar out-of-band token based model to allow access with their nova-vncproxy.

Some links:

kanaka
  • 70,845
  • 23
  • 144
  • 140
  • Thanks for the excellent and complete answer (as usual). I'm quite new to the python world and all those sources, especially nova, seem to be deeply integrated with framework; thus i'm not able to get it out of it 'easily'. Gived a try to VNCAuthProxy but also cannot get it to run (see http://code.osuosl.org/issues/4101). – Disco Apr 19 '11 at 10:58
  • I must be missing something really obvious here but can't figure out what. Also it would be soo great that someone could write an 'out-of-the-box' solution that anyone could use in their internal projects (without guru python skills). Glad if you could help me with that :) – Disco Apr 19 '11 at 11:00
  • @Disco, yes, host:port selection is closely bound to authentication/authorization. If you have a lots of VNC servers then you probably have some sort of framework or system that you are using to manage them. The setup/authorization of noVNC to connect to those systems should be linked into that framework. If you just have a couple of VNC servers then you can just launch a couple of websockify instances for them. You are probably in that in between place where you want some websockify automation but don't have a framework. Continued in next comment... – kanaka Apr 19 '11 at 15:05
  • ... continued. I made a quick and dirty patch that might do what you want. It allows the target port to be passed as part of the WebSockets handshake (in the path) and it limits the port to the 5900-5999 range. I'm not committing it to the main stream since this opens some security concerns and you'll want to be careful, but it might work for you: https://gist.github.com/928289 – kanaka Apr 19 '11 at 15:09