HTTP over websockify

223 views
Skip to first unread message

Jonathan Bennett

unread,
Oct 11, 2015, 3:05:21 PM10/11/15
to noVNC
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

Joel Martin

unread,
Oct 13, 2015, 1:36:43 PM10/13/15
to noVNC
Jonathan,

That's a really interesting idea. And fwknop with SPA is really cool. I'm not an iframe expert by any means so I can't really help much on that front. However, I think an even more interesting approach is to look at Service Workers. Service Workers have a similar API/design to Web Workers, but they enable a whole new set of functionality. Specifically, Service Workers are able to intercept network requests from the page that started the service worker. The nominal reason for doing this is to enable a whole new domain of smart offline applications. However, one thing you might be able to do is intercept normal web requests from the page and funnel them over a websocket connection to websockify.

I think the main limitation is that the first page load (including the service worker) needs to succeed before the service worker starts. But, on the other hand, Service Workers can be scoped to a bigger target than just a single page (i.e. whole subdirectory of a domain). So a single Service Worker could apply to a whole domain in theory. So the browser would need to load some small page from that domain that is not fwknop protected (or some other way of temporarily granting access to a given client IP first). Once that is loaded, any time a browser request is made to that scope, the Service Worker would receive the request and can do whatever it wants with it.

Basically, your Service Worker would hook the this.onfetch event and marshall the request into a websocket message to websockify, and then when the data comes back, it would respond back. The main complexity I think will be with correlating requests and responses from the websockify connection. You might need multiple websocket connection and only have a single HTTP request outstanding per websocket connection (basically like HTTP pipelining). But it all seems fairly tractable (if perhaps a bit mind-bending).

Couple of quick links to get you started:


Do you have somewhere where you are doing/tracking this work? I'm very interested to see how it goes and track progress.

Joel Martin (kanaka)

Joel Martin

unread,
Oct 13, 2015, 1:45:14 PM10/13/15
to noVNC
Jonathan,

Another thought. This seems like a perfect application of Service Workers beyond the initial goal of offline applications. Service Workers are being designed to be somewhat generic even if the primary goal is offline apps. Adding a security layer to web surfing seems well within scope. And this is definitely the right time to begin exploring this. This is a web standard that is in progress as we speak (http://www.w3.org/TR/service-workers/). So if you run into roadblocks with Service Workers in trying to implement this, you should definitely communicate with the working group and let them know what you are trying to do and the problems you are running into so that the spec can be adjusted to support this sort of application.

Joel

Jonathan Bennett

unread,
Oct 13, 2015, 4:20:51 PM10/13/15
to noVNC
Joel,
    This is a good idea.  I'll dig into service workers and see if it would fit the idea I'm after.  I might touch base with the working group for the standard as well.  I don't have any code written to speak of, still mainly doing research.  Any code that gets written would show up at my github account: https://github.com/oneru?tab=repositories

Thanks,
Jonathan

Joel Martin

unread,
Oct 13, 2015, 4:58:47 PM10/13/15
to noVNC
Just discovered a really nice presentation on Service Workers:  https://bit.ly/sw-nyc
Reply all
Reply to author
Forward
0 new messages