3 ms·

HTTP(S) might just be the wrong protocol for initial setup of a router! Maybe instead generate a password for each router and print it on the box along with th

HTTP(S) might just be the wrong protocol for initial setup of a router! Maybe instead generate a password for each router and print it on the box along with the device's unique SSH Key fingerprint. Technical users can then SSH in and bootstrap the system (also generate/upload their own TLS certs if they want to use a browser and connect over HTTPS, etc). Non-technical users get an app and they can scan a QR code on the box which has the SSH user, password, and fingerprint for verification. The App connects to the router over SSH to do router setup. If an App is involved you wouldn't technically NEED to use SSH with the App but it was the first thing that came to mind.

fulafel 7y ago
I think https could work fine, just give each device a unique key and dns name.
- actionowl 7y ago
  That approach has been mentioned in the comments. Some problems with it are: If a certificate is valid beyond 825 days Chrome will not honor it. So if you generate a key and cert at the factory for every device you run into the issue of the end-user getting a device with an expired cert. If you generate a unique key and self-signed cert users will complain and call support about the "insecure" site warning. Communicating upstream to a third party to get a cert won't work for all users (e.g. those that need to configure a static IP from their ISP.)
  - fulafel 7y ago
    You shouldn't plug something with more than 2 years of missing security updates to the internet anyway (or sell it). Reflash & restock time by then.
xg15 7y ago
> Non-technical users get an app ... So now I need an already-working smartphone to set up my internet connection.
- actionowl 7y ago
  That's a good point actually. You'd need the internet to install the app too.
eldakka 7y ago
This could be extended to something like: Ship a USB stick with the device with installer software on it. The installer software sets up an SSH tunnel to the device, so it includes an SSH client and a script (batch) file that effectively does: SSH -Llocalhost:<some random local port>:localhost:<installer initial port> setup@<ip address of device> It has the known SSH signature of the device in its known_hosts, and of course the user has to type the password from the sticker on the device. Then it fires up the browser with the url http://localhost:<local http://localhost:<local port used in previous step> which has access to the full setup of the device via the browser. It is HTTP, therefore there are no initial setup TLS issues with the browser, as you are going via an encrypted tunnel set up via SSH using HTTP encapsulated within that encrypted tunnel (effectively a temporary VPN) rather than using TLS. As part of the setup process, the device generates a self-signed cert, which you can put in your computers/browsers trusted cert store for future use. Also as part of the setup, once the self-signed keys and certs are generated, it disables this local HTTP webserver that is being forwarded to via SSH, so in future the user can use a standard TLS connection to the device using the generated certificates. If a factory reset of the device is done, it blats its config and re-enables the 'setup' webserver (that is only running on localhost therefore can only be access locally,i.e. via SSH tunneling).

fulafel 7y ago

I think https could work fine, just give each device a unique key and dns name.

actionowl 7y ago
That approach has been mentioned in the comments. Some problems with it are: If a certificate is valid beyond 825 days Chrome will not honor it. So if you generate a key and cert at the factory for every device you run into the issue of the end-user getting a device with an expired cert. If you generate a unique key and self-signed cert users will complain and call support about the "insecure" site warning. Communicating upstream to a third party to get a cert won't work for all users (e.g. those that need to configure a static IP from their ISP.)
- fulafel 7y ago
  You shouldn't plug something with more than 2 years of missing security updates to the internet anyway (or sell it). Reflash & restock time by then.

xg15 7y ago

> Non-technical users get an app ... So now I need an already-working smartphone to set up my internet connection.

actionowl 7y ago
That's a good point actually. You'd need the internet to install the app too.

eldakka 7y ago

This could be extended to something like: Ship a USB stick with the device with installer software on it. The installer software sets up an SSH tunnel to the device, so it includes an SSH client and a script (batch) file that effectively does: SSH -Llocalhost:<some random local port>:localhost:<installer initial port> setup@<ip address of device> It has the known SSH signature of the device in its known_hosts, and of course the user has to type the password from the sticker on the device. Then it fires up the browser with the url http://localhost:<local http://localhost:<local port used in previous step> which has access to the full setup of the device via the browser. It is HTTP, therefore there are no initial setup TLS issues with the browser, as you are going via an encrypted tunnel set up via SSH using HTTP encapsulated within that encrypted tunnel (effectively a temporary VPN) rather than using TLS. As part of the setup process, the device generates a self-signed cert, which you can put in your computers/browsers trusted cert store for future use. Also as part of the setup, once the self-signed keys and certs are generated, it disables this local HTTP webserver that is being forwarded to via SSH, so in future the user can use a standard TLS connection to the device using the generated certificates. If a factory reset of the device is done, it blats its config and re-enables the 'setup' webserver (that is only running on localhost therefore can only be access locally,i.e. via SSH tunneling).