Hello, I'm working on an interesting problem, and am impressed with websockify and the novnc solution. I'm one of the developers of Fwknop (
https://www.cipherdyne.org/fwknop/). We do a modern take on port knocking, called Single Packet Authorization, that uses real crypto to open a firewall port for an authenticated user. This works great for ssh and similar protocols. A longstanding problem that we have is trying to support HTTP. Specifically, the way Fwknop works is that it adds a firewall rule that allows the authorized IP address to connect to the protected service, and then that rule is removed after a short timeout, usually 30-120 seconds. This works fine for ssh, as ssh maintains a tcp connection that lasts until logout. The firewall sees it as an existing connection. With HTTP, a new tcp connection is launched for each new page load, so once the firewall rule times out, new page loads are blocked. We have worked around this by tunneling port 80 over ssh, but this approach is difficult on Windows machines. The ideal solution would run entirely in the browser and not require the installation of any additional software (We're currently developing a system that uses an Android app to send the SPA packet, and therefore avoid any special software on the desktop.)
A potential solution is to establish a websocket connection that will be persistent, and then do all the communication with the server using that websocket. This would be the single page application approach. I've found websockify, and this leads to another idea, a way to support web applications that have not been written as single page applications. Could we load an initial page that sets up the websocket, and then load internal pages in an iframe, using the websocket and websockify as a proxy connection? Websockify would make it easy to point that websocket tunnel at an internal web server. The bit I haven't figured out is how to tunnel the iframe's traffic through the websocket. Doing some automated page rewriting at the server is an option. The ideal way to handle this would be similar to how ssh can do a simple port redirect, but from what I understand, browser sandboxing prevents a script from opening an accessible listening socket (Can't bind the websocket to port 8080, for example). Is there a solution here that I'm overlooking?
I do see that novnc *could* work, but for the use-case we have, this seems like a really heavy solution that wouldn't scale very well.
Thanks for any help.
--Jonathan Bennett