7

I'm building a Raspberry Pi-based device for backyard gardeners that has a web page and access point for the initial configuration, including the Wi-Fi configuration. The connection uses WPA2 and the only two devices on that internal network would be the device itself and the user's phone/tablet/laptop. The access point is only visible during configuration which reduces the likelihood of outside attackers being able to guess the random, factory-shipped password. So I have encrypted traffic, almost certainly only two nodes, for a short time, and a random password. Thus there is no need for HTTPS that I can see, and I had planned to run HTTP.

However, today I learned that starting in July Chrome will begin marking all HTTP sites as insecure.[1] But because the Wi-Fi configuration will be done by access point, no internet access is available yet to verify TLS certificates, which I understand is necessary for proper operation.[2] I could self-sign the cert, but that presents other problems.[3]

So my options seem to be:

  • Present the configuration page with a big, scary, "This website is not secure" message
  • Present the configuration page with a big, scary, "This certificate is not trusted" message (e.g. self-signed)

How would you provide that lovely green lock by default for a device configuration page?

[1] https://www.theverge.com/2018/2/8/16991254/chrome-not-secure-marked-http-encryption-ssl

[2] https://security.stackexchange.com/questions/56389/ssl-certificate-framework-101-how-does-the-browser-actually-verify-the-validity?utm_medium=organic&utm_source=google_rich_qa&utm_campaign=google_rich_qa

[3] https://www.globalsign.com/en/ssl-information-center/dangers-self-signed-certificates/

  • Part of your question is based in misunderstanding: you do not actually need access to the Internet at large to verify a certificate. The certificate chain file on the device needs to trace back to a root of trust known to the browser. If it doesn't, merely having Internet access won't be enough, a process would actually have to be followed to add an additional CA to the browser. – Chris Stratton May 1 '18 at 12:58
  • I already do have a cert trusted by most browsers for my main website. So would I just use my existing cert say, if it were a wildcard, that is already trusted by iPhones and Androids? – Slow Bro May 1 '18 at 13:07
  • No. Absolutely not!!! if you did that, you'd be giving away the secret that would allow impersonating your website to everyone who bought one of your products. The cert you use for this purpose needs to be only used for this purpose and considered compromised from the start. If you need to protect users from each other, you'll need a unique cert per box made. That's relatively easy to do with a custom CA for a client you control like a custom mobile app, but much harder to do for a browser having only stock roots of trust. – Chris Stratton May 1 '18 at 13:19
  • 1
    To have a unique cert per device, you need a CA willing to economically sign a lot of them. If you can make a custom client like a mobile app you write, then you can make it trust your own custom CA. But if your boxes need to be trusted by stock browsers with stock trust lists, then you'll have to work with a recognized CA. – Chris Stratton May 1 '18 at 14:15
  • 1
    Thank you, this is becoming more clear now. Why don't you post this as an answer and I'll upvote it? – Slow Bro May 1 '18 at 14:25
4

One possible option is to use HTTPS and ship a real certificate on the device:

Since you control the access point you presumably control the DHCP server on the access point, so you can have it provide a DNS server address at the same time.

This DNS server can be on the AP and can resolve a fully qualified hostname to point to it's self.

You can then purchase a certificate for that fully qualified domain name and bundle this with the product to create a fully verified HTTPS connection.

One big problem with this idea is that you are shipping the private key and cert for that domain name, so you should assume it will be compromised at some point so you should never put a real machine (You may need to run a machine with this name for a very short time to actually get the certificate) on the internet that uses that host name as attackers would be able to easily spoof it.

Also the firmware for the AP would have a limited life as the certificate will expires (probably after a year by default iirc) then you would get nasty certificate expired warnings.

Next Idea:

Ditch WiFi Access Point mode and use Bluetooth e.g.

https://www.hardill.me.uk/wordpress/2016/09/13/provisioning-wifi-iot-devices/

Downside is that Apple doesn't currently support WebBluetooth, but Chrome on Windows/Linux/Mac does and you could ship a native iOS app for Apple phone/tablet users.

| improve this answer | |
  • So I’m envisioning this, based on your answer: Set up DNS and DHCP in the device. One of the DNS records is device1234.myrealdomain.com, where myrealdomain.com is um, my real domain :-) The device1234 cert was signed by my CA before leaving the factory, and the iPhone/Android has that chain of trust already embedded, and knows to trust that device. I don’t have to have internet access to verify, and when the cert is about to expire I push down a newly signed cert. Would that work? – Slow Bro May 1 '18 at 13:08
  • No, you absolutely must not use a cert relied on for anything meaningful (like your website) for this purpose, because you'll be distributing it to lots of boxes. When you do that, you are effectively publishing the supposed-to-be-secret part for all to see. You'll also need something with a much longer expiration time than many CAs give out today - otherwise a box that sat powered off for a year or two couldn't on being plugged back in be accessed by an enforcing browser even long enough to configure it to access the Internet so that it could pull down an updated cert to satisfy the browser. – Chris Stratton May 1 '18 at 13:30
  • Chris have a look at my response just above yours, in which I describe a situation where I ship device-specific certificates, not the main website cert, with each device. In the event that the device sits offline longer than a year I would consider that broken. These are not going to be manufactured and sit on a shelf, they will be configured just before leaving the factory. – Slow Bro May 1 '18 at 13:37
  • If you have your own CA then you don't need the DNS server, you can issue certs for the IP address of the device which makes everything simpler. And the certs can expire when you want – hardillb May 1 '18 at 13:43
  • 2
    A 90-day cert is completely, totally, utterly, and absolutely non-viable for packaging in a hardware product. It would be a customer support nightmare and probably sink your business. Don't do it. Don't even think about doing it. – Chris Stratton May 2 '18 at 2:12

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.