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.

[X-Ryl669]

If I take the example of a network camera, there are chances that it'll be installed outside, visible for all. In that case, you certainly don't want a PIN or the serial number (or any information that's visible on the device itself) to be the way to authenticate on the camera.

As you said, the threat is not the same for a printer that's on your desk since it's not accessible to attacker (shouldn't be, unless you put the face with the serial number/PIN close to the window 🙄).
All in all, this means that this PIN based solution is not universal or good enough.

I don't know about the true security of the WPS push button, that is, when you try to authenticate, you're required to press a button on the device within a limited time range (usually 30s). This does not require a monitor/screen on the gizmo (just a $0.1 button), and can be made quite secure (you'd need to press this button the first time only when you're pinning the certificate). For a device that's installed in a public place (like a network camera), you could have the option to disable the button feature once it's installed (or 30s after the device power on). From a protocol point of view, I imagine a 3 step process:

1. Host ask the device a valid "join" proof (the host generated a random secret and ask the device to sign it with its certificate), and displays to the user "Press device button"
2. User press the device button (if possible) and this triggers the device to sign the "last" host received secret and sign it with its certificate.
3. Device sends the signature to the host plus some HMAC (JWT ?) it generated. The signature should asserts against the device public key for its certificate. If it's valid, the host pins the certificate for the device and store the HMAC to later present to the device for authentication.

An attacker can/should not be able to press the button that's signing the random secret, thus will never get the device's HMAC and as such could not modify the device.
Similary, once a user wants to connect to the device she has to physically go to the device to press the button, so a MITM/attacker has very small chance (but not zero) to cloak as a device here. Even if he emits his own certificate + HMAC every second (and thus, have the host use his information instead of the device), he must capture the device's HMAC and send a host "join" request in the limited time range where the user pressed the button to be able to talk to the device and proxy the communication from the host to the device.
That's a very unlikely event.

[thw0rted]

The most sensible solution that I can see is to standardize several approaches and leave it to the vendor to decide which is appropriate for their use case. As you point out, the best solution for a printer might not be the best one for a security camera, or a NAS, or a media streaming device, smart display, etc etc. I think that all falls under issue #3?

[guest271314]

Is this draft proposal still being pursued?

[dajiaji]

@guest271314 This activity has been pending for the last two years, but I'm thinking of resuming it soon. Do you have any comments or suggestions?