Users communicate with NETLAB+ using a web browser. Currently this communication uses unencrypted HTTP. Many users have requested that we use HTTPS and SSL to provide secure encrypted communication — and we are working on that. I mentioned in my last post that HTTPS and SSL will eventually be required to eliminate Java from our client applications. Here is a quick summary of the work that is occurring on this front:
1) Work with our legal council to comply with export and import laws. Encryption is regulated in many countries, and including the U.S. where NDG is based. This is why providing HTTPS and SSL is anything but a no-brainer.
2) Change our web server to support HTTPS and websockets.
3) Add an interface to manage SSL certificates and certificate signing requests. Note that NDG will provide a dummy certificate, but it will generate a browser warning.
4) Convert all Java applications to native browser applications using HTML5 and websockets.
I expect that once we clear the legal hurdles (step 1), we’ll be able to provide a release to support HTTPS and websockets (step 2 and 3) in the short term. The conversion from Java to websockets has been underway for some time, but this is a big effort.
Q: What changes will be required at the NETLAB+ site to support HTTPS and the new client applications?
1: Open TCP port 443 at the NETLAB+ site’s firewall to allow HTTPS connections.
2: Obtain a valid SSL web server certificate for the NETLAB+ server.
3: Register the NETLAB+ server in your DNS.
Q: What changes will be required by users?
1: Users will need a modern web browser that supports HTML5 and websockets (IE10 or higher for example).
2: Users will need to type the DNS name of the NETLAB+ server in the browser address bar. Accessing the NETLAB+ server by IP address will generate security warnings.
Q: Can port HTTP (port 80) be closed once all applications are using HTTPS (port 443)?
A: Yes, although you will have the option to redirect HTTP connections to HTTPS so that the user does not have to have to remember to type https:// in the browser URL bar. In this case you’ll want to leave 80 open.
Q: Will the new client applications support HTTP (port 80) when the become available?
A: This may be a configurable option, but it is not likely to be supported. Websocket connections may work fine within a campus if they do not traverse firewalls or HTTP proxy servers. Outside of a campus, HTTPS will be required so that these devices do not break the applications. The main use case for keeping HTTP would be for sites that cannot use HTTPS for legal or policy reasons. We are experimenting with open source proxy solutions that can be used with NETLAB+ for situations where native HTTPS can not be imported and/or used.
