A draft proposal for supporting local HTTPS communication.

[dajiaji]

Sorry for my late submission.
We have written a draft proposal to enable HTTPS communication between a web browser to a local server that has a private domain name such as 'device.local'.
https://github.com/dajiaji/proposals/blob/abstract_proposal/draft_proposal_supporting_local_https_communication.md

I'd appreciate it if you could give me your comments and feedback.

[tomoyukilabs]

Thanks a lot for your initial proposal, @dajiaji! While there are so much technical details, I expect that they will be good starting points. I will create meta issues to decompose and categorize them, but we can still review and discuss your comprehensive proposal here.

[daniel-kun]

I've read through @dajiaji's proposals, and I think they are suitable to address the currently pressing needs for Smart Home / IoT scenarios very well.

Can the proposed PIN be something that has been printed on the device - and probably be changed during setup? We (https://www.gira.com/) currently ship our devices with unique initial device password that is printed in plaintext and QR-code on the back of the devices, which seems to be a good candidate for this.

[dajiaji]

Can the proposed PIN be something that has been printed on the device - and probably be changed during setup?

Yes, of course. Your product is a typical case suitable for my approach ＃1.

[X-Ryl669]

Approach 1:

• I don't think it's a good idea to specify the protocol for password exchange.
• Please notice that the device might not need authentication (for example a printer, you don't need to authenticate to print, but you don't want other user to see what you're sending to the printer), so there might be no password either. Also, how do you populate the password at first ?
• Not all device have screen or way to display a PIN (like a network camera for example). It can't be printed either (because... well, password on post-it is a bad idea).

Approach 2:

• You need internet access. That rules out any intranet only network.

Approach 3:

• This is a good idea. I think allowing to delegate the certificate to a remote (trusted) source is good. That means that the device and the remote source share a secret (either stored while manufactured, or negotiated when the device is set up) to ensure that no MITM can impersonate the server. The browser should pin the certificate or delegation just like it's storing the exception for Self signed certificate. That could also work in intranet only network if one secure host is present on it.

[daniel-kun]

• Please notice that the device might not need authentication (for example a printer, you don't need to authenticate to print, but you don't want other user to see what you're sending to the printer), so there might be no password either. Also, how do you populate the password at first ?

I would consider it pretty fair to require a password/PIN when you want to establish a local, secure connection. I honestly don't see the requirement to connect to devices without authentication. Sure, it's more troublesome than today, but that's the price that you pay for security, IMHO.
Sonos (the awesome WiFi-speakers), for example, gives you full control over their speakers in your LAN, without any further ado. I don't like this at all and would like this not to be possible in the future with local HTTPS. Just my 5ct.
On the other side, it's important that you do not force clients to store your plain-text password locally, of course, since good encryption is not that easy on a local device.

[X-Ryl669]

The issue I see with authentication is that you must have a initial password to bootstrap. Most of the time, the initial password is dumb (like "admin") and no consumer changes it. So, you might end up with a 10 feet wide security wall but with a door wide open. IMHO it's even worse since people will see the authentication screen and will think they are "safe", and are more likely to connect the gizmo to the internet.

But I agree with you on that point, a initial secret (like a PIN or a code that's only written on the device's tag itself) is better than none.

[dajiaji]

... I don't know why but I haven't received the notification for your mentions, @X-Ryl669 @daniel-kun. Thanks for your comments!

I understand your concern about using initial password.

Also, how do you populate the password at first ?

Honestly, I attached weight to a PIN code (bound to a device), rather than a password (bound to a user) on Approach #1. In my assumption, the PIN code is generated randomly and displayed on the device's LCD, or it has been written on the device's tag as a unique device identifier. Then, it is used by a pairing method based on the proximity of the device before establishing a TLS session.

IMHO, once the device can run an embedded HTTPS server after the pairing, user authentication on the device can be delegated to an IdP (google, etc.) with OAuth2/OIDC. In this case, I think there is no need to use initial password any more.

Approach 3:
This is a good idea. I think allowing to delegate the certificate to a remote (trusted) source is good.

Thanks. I like this approach but there are many things to do (be standardized).
If you have some additional ideas, feel free to send a PR.

[tomoyukilabs]

@dajiaji There was something wrong with email forwarding. I've fixed the problem, and it is working properly now. Sorry for inconvenience.

[thw0rted]

I honestly don't see the requirement to connect to devices without authentication.

There is value in a protocol to authenticate devices that are open to the whole network. I believe Chromecast has a good implementation of your Sonos example. I am able to make an (authenticated) connection and turn on a "party" mode where anybody on my network can send content to it. I think it's important to be able to turn that off as well, but that's outside the scope of this repo.

...how do you populate the password at first ?

Think about routers that ship with a WPA PIN printed on the bottom. Putting aside the technical issues with how WPA PIN security was implemented, the idea is sound. You pick up the router, look on the bottom, and there's a unique(ish) code that you use to connect.

• Not all device have screen or way to display a PIN (like a network camera for example). It can't be printed either (because... well, password on post-it is a bad idea).

Password on a post-it is a bad idea if your threat model is unauthorized people having physical access to the place you keep the post-it. That's not what this proposal is about. The misunderstanding here is that the PIN is authenticating the device to the user, not the other way around. You just as well have the confirmation dialog request (a hash of) the device's serial number. Knowing the serial number should not be enough information to give me access to change my router's configuration, but it is enough to let me know that I'm sending my printout to the printer on my desk, not a malicious one that presents itself with the same identification.