Securing WIFI for a web application

Question

I have created a CORS web application (only javascript), where I want to be installed and run under different LANs.

I'd like to put SSL, but I don't know what the exact configuration of the lan will be and probably it will be different every time. So I think I can't add a certified SSL. Is there any possible other solution with SSL? I don't like the approach of adding an uncertified SSL because of the warnings.

How else can I encrypt the packages and make secure authentication of the requests? I am using CouchDB default CORS but the packages can be sniffed if the web application is installed and used in an open WIFI. The application is using only javascript and I don't know how I can protect it (the only backend is the storage in the couchDB).

Answer 1

The design of your CORS-enabled application is not directly related to whether it uses SSL. See this section of the CORS specification.

Designing your application to support CORS and serving your application over an SSL connection are separate decisions and might not even be made by the same people. When you say "installed and run under different LANs", I assume you mean that different people/companies will host your server-side code, possibly under different domains.

You should not even assume that the web server hosting your code is the same as the web server doing the SSL, as the SSL termination might be a different device that then proxies requests back to the web server.

What I would do in a case like this document the potential need for SSL in your installation instructions and let people do it (or not) in a way that's appropriate to their environment.

Answer 2

From how I understand your question (JavaScript only), you might use a single HTTPS host to serve the JavaScript files, just like Google's hosted libraries.

If the CouchDB hosts are not going to be in the cloud, you should assign individual (cheap) SSL certificates to them. The clients should be able to fork over ~8$/year for transport layer security if security really matters to them.

Answer 3

So, if I understand your question correctly:

• You have a web application that can be accessed using cross-origin requests.
• This application will be deployed on local networks, i.e. it will be accessed via a non-public IP address (the machine serving it being in that network, I'll call it "local server").
• You want to protect the link between the client and the local server, preferably using SSL.

You can do that! Make whoever has control of the local server get a SSL certificate for somesubdomain.SomeDomainHeControls.com, deploy that certificate to the local server, and point that subdomain to the local IP. When the application is then accessed via that address, you will not get any warnings and the connection will be secured. As long as the client only accesses your application using that domain, this is secure, since only the owner of the server has access to the key.

If you control the local server yourself (noone can extract the private key), you can simply get a wildcart certificate for *.aDomainForThisPurposeThatYouControl.com, and create a subdomain for each deployment, pointed to the appropriate IP.

If you do not control the local server and whoever does cannot get his own certificate, you could get individual certificates for them. This would mean you create deployment1.aDomainForThisPurposeThatYouControl.com, point it to the local IP, create a regular, single-host certificate for that name, and install it on the local server. As a safety precaution, do not use that domain for anything else, since you have given out private keys for hosts on this domain.

You could also host the application itself on an external server under your control, if the local networks have access to the internet. Deploy regular SSL to that server. After the application itself has been loaded from the external server securely, it can make plain HTTP requests to get data from a local server. This will trigger a "mixed content" warning, but no SSL error. You can then use JavaScript-based encryption to protect the data. For example, if you only want to protect data going from the client to the server, your external, trusted server could provide the client with trusted JS crypto libraries and the RSA public key of the internal server (via the SSL-authenticated connection), then you just encrypt your data on the client side before sending it over plain HTTP. In theory, you could even create a SSL client in JavaScript, provide the script and a trusted server certificate to the client, use a HTTP or WebSockets tunnel, and over this tunnel, run your own SSL connection between the local server and the JavaScript client. This is, of course, not very practical, but secure (since the JS is downloaded via a secure connection). You can also just load a small JavaScript from the trusted server, which then downloads the rest from the local server, verifies a signature/hash, and executes it. Megaupload is doing something like that.