Best practices for a WiFi-connected device WITHOUT Internet connectivity

Question

The company I work for makes a device that offers a Web-based setup and operation interface via WiFi. The device will typically be used out in the middle of nowhere, so the presence of an existing WiFi network cannot be assumed: the device's WiFi module therefore operates as an Access Point, and serves up the fancy HTML5 web app over HTTP (the only option available with the WiFi module I chose back in 2013, when this was originally implemented).

This worked great at first, but it's slowly falling apart as the Web evolves. Two problems in particular:

• Part of the web app involves mapping, and of course it's quite useful to be able to show a "you are here" marker on a map - but Chrome already refuses to support the HTML5 Geolocation API over HTTP (without even an option to explicitly trust the page), and it looks like all the other browsers will follow suit.

• The web app is pretty big (and the WiFi module pretty slow), so I use the HTML5 Application Cache feature to get effectively instant page loads after the initial use of the app. Unfortunately, major browsers are already refusing to allow this feature over HTTP, the feature is being deprecated anyway, and it's successor (Service Workers) is explicitly HTTPS-only.

I'm having to redo both the hardware and software of this feature, as the original WiFi module is no longer available. The modules available these days have lots more CPU power and storage (and cost a tenth as much), so it's now practical to do lots of things such as serving the web app over HTTPS. The advice I'm universally seeing for devices like this is to get a proper SSL certificate, but I don't see how that could possibly work in my case:

• There will not normally be an Internet connection available when the device is actually in use, so the certificate couldn't be verified.

• The device is accessed either by its IP address 192.168.1.1, or via the LLMNR/mDNS name ui.local. SSL certificates are not offered for either type of address.

• I need this to work forever - there's no mechanism in place for updating the certificate in the device. Even 10 years (the longest validity that many self-signed certificate generators offer) would be inadequate; I refuse to build planned obsolescence into the device.

It could perhaps be made to sort of work by adding a DNS server to the device, basically making it a captive portal, so that it can be accessed via a normal URL that I can actually buy a SSL certificate for. However, I see lots of potential problems with this:

• It fails if the user's computing device is set up with a static DNS server address (8.8.8.8 or whatever), rather than accepting one from DHCP.

• It fails if the user actually has an Internet connection at the same time as the device's WiFi connection.

• It fails permanently if DNSSEC ever catches on.

• There's still the issue of certificate expiration.

That would appear to leave a self-signed certificate as the only workable option, despite all the advice to the contrary. One common objection to them is "you're teaching users to ignore valid security warnings"; I see your point, but what am I supposed to do instead?

Is there some approach I've overlooked, that would let my device continue to work with modern browsers as well as it did back in 2013?

Answer 1

I agree with you that accessing a device in a LAN without public address via HTTPS is tricky problem.

IMHO there should be a special TLS version of addressing those devices, however at the moment no such standard exists.

From my point of view only a self-signed certificate seems feasible. However when you are talking about "self-signed certificate generators" it to gives me a chill because you should never ever equip a a device with a pre-generated self-signed certificate! This is one of the worst things you could ever do from a security perspective because pre-generated certificates and key pairs can always be extracted from the firmware and then used to attack one of your customers (Lenovo and other computer manufactures just learned that in the last years the hard way)! When it comes to self-signed certificates there is only one way:

1. When the device first start-up wait until enough data has been processed (seeding) so that the random generator can generate secure random data.

2. Generate a public/private key pair using the generated random data

3. Generate a self-signed certificate using the previously generated key-pair. Using the right command you can set the validity end to any date you want.

Note that you can re-do step 3 at any time, e.g. when the user reconfigures the IP-address and you have to update that in the certificate. For self-developed clients (e.g. on Android or iOS) you could do public key pinning which would mean that the certificate does not have to be (re)installed.

Unfortunately for web browsers a new certificate even with the same public key means that you have to re-install the certificate as trusted.

Regarding the HTML5 Geolocation API: Can't you use this API via HTTPS? Mixed content is only a problem if you use HTTP resources in a HTTPS page, but the other way round there should not be a problem.

BTW: I found some slides that may be interesting for you, even if in that scenario Internet access is possible. May be you get some new ideas from it: https://www.w3.org/wiki/images/6/6c/TPAC2016_Local_Discovery_and_HTTPS.pdf