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
  • 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 01 '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 01 '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 01 '18 at 13:19
  • I wasn’t speaking clearly, I had in mind individual certs for each device shipped with the device, not my main website’s cert on each device, which would indeed be insecure. But it sounds like you’re saying this is not possible without using an app? I could publish an app if that is what is required. – Slow Bro May 01 '18 at 13:35
  • 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 01 '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 01 '18 at 14:25
  • I didn’t know what to Google or I would have seen this is a common problem called Wi-Fi provisioning. Using the classic Access Point approach as I describe above is fraught with gotchas that make initial user experience a big negative: The aforementioned TLS issues, then there are some phones that won’t connect to the AP when they sense no internet connection, the technical expertise required to switch networks, and what else? Likely I’ll provide an app, and broadcast from the device that it is discoverable. Maybe provide multiple methods such as USB, (insecure) WPS, etc. More may be better. – Slow Bro May 01 '18 at 18:06

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,553
  • 1
  • 20
  • 34
  • 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 01 '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 01 '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 01 '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 01 '18 at 13:43
  • But also if this is for a production line solution why do you care about the warning, it's easy to train the folk doing the configuration to ignore the warnings – hardillb May 01 '18 at 13:45
  • This is for end users at houses, not production line. End users expect minimal interference. So did I understand you correctly in my response above? – Slow Bro May 01 '18 at 14:01
  • Yes, but you will need to buy a certificate from a public CA so users don't have to import your CA trust cert in their browser/phone. And you should NOT use a wildcard cert. – hardillb May 01 '18 at 14:03
  • @SlowBro - when you say "In the event that the device sits offline longer than a year I would consider that broken." do you really mean you would consider the user to have broken their device if they put it in a box in the storage closet for a year during which the cert expires, then plug it back in and try to use it? Hopefully not. – Chris Stratton May 01 '18 at 14:05
  • @ChrisStratton That's what I had in mind, and by the way this is a backyard farm Raspberry Pi-based IoT device. Three possibilities at that point: 1.) They would plug in the device, and the former Wi-Fi configuration, main website username/password, would all still be valid. The device connects and downloads an updated local cert. 2.) The Wi-Fi or username/password has changed, and they could with assistance on the phone accept the expired cert, and when it finally connects it gets the updated local cert. 3.) I could mail a new SD card with new local certs. Can you think of a better way? – Slow Bro May 01 '18 at 14:20
  • @hardillb "Yes, but you will need to buy a certificate from a public CA so users don't have to import your CA trust cert in their browser/phone. And you should NOT use a wildcard cert." So you would say that I would buy lots and lots of certs from the public CA, one for each device yes? Or LetsEncrypt and use free (90 day) certs. – Slow Bro May 01 '18 at 14:21
  • One cert, deployed to all instance of that device. LetsEncrypt is no good because you absolutely can not be sure a customer will use a device in the first 90 days of getting it. Or what happens when they change ISP and need to set up a new WiFi network 2 years later. – hardillb May 01 '18 at 14:24
  • @hardillb "LetsEncrypt is no good because you absolutely can not be sure a customer will use a device in the first 90 days of getting it. Or what happens when they change ISP and need to set up a new WiFi network 2 years later." See my comments above. I believe there is a path for expired certs, but that would have to be a business decision I would have to make and not a technical challenge, unless I am just wildly mistaken. – Slow Bro May 01 '18 at 14:27
  • An expired cert shows the same warnings as a self signed cert – hardillb May 01 '18 at 14:28
  • Indeed it does. They could with assistance on the phone accept the expired cert, and when it finally connects it gets the updated local cert. – Slow Bro May 01 '18 at 14:30
  • But they only need to access this once to get wifi details on to the device, if they are happy to accept it they will never see the smooth work flow because by that point the device is configured – hardillb May 01 '18 at 14:32
  • 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 02 '18 at 02:12