8

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/

Slow Bro
  • 83
  • 6

1 Answers1

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.

hardillb
  • 12,813
  • 1
  • 21
  • 34