A draft proposal for supporting local HTTPS communication.

dajiaji commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

... 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 commented 5 years ago

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

thw0rted commented 4 years ago

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 commented 4 years ago

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:

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"
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.
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 commented 4 years ago

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 commented 3 years ago

Is this draft proposal still being pursued?

dajiaji commented 3 years ago

@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?

guest271314 commented 3 years ago

Well, yes. A fair amount. This gist is in this Chromium FUGU request that was closed today (under suspicious reasoning) https://bugs.chromium.org/p/chromium/issues/detail?id=1115640.

I have essentially been able to achieve what is expected here, I am not just attempting to improve performance by attempting to correlate existing technologies into a cohesive API. There is resistance from specifications and implementers, for what reason I cannot tell you, perhaps you can gather why they close the issues I have filed.

https://groups.google.com/a/chromium.org/forum/?utm_medium=email&utm_source=footer#!msg/chromium-extensions/BnsgStmVOMc/7E0mXxI-AAAJ

guest271314 commented 3 years ago

I am highly

@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?

I am highly skeptical about specifications. W3C banned me.

Nonetheless I am willing to help here with concepts and primarily testing in the field. QuicTransport (https://github.com/guest271314/quictransport; https://github.com/guest271314/webtransport) was close to the requirement here, then was deprecated.

I am currently using a Chrome extension to request localhost on any origin.

guest271314 commented 3 years ago

@dajiaji Check this out.

Introducing WebContainers: Run Node.js natively in your browser

Today we're excited to announce a new technology we've been working on in concert with the teams at Next.js and Google.

A few years ago we realized that the web was heading towards a key inflection point. The advent of WebAssembly and new capabilities APIs made it seem possible to write a WebAssembly-based operating system powerful enough to run Node.js, entirely inside your browser. ...

Today we're excited to announce WebContainers. WebContainers allow you to create fullstack Node.js environments that boot in milliseconds and are immediately online & link shareable—in just one click. The environment loads with VS Code's powerful editing experience, a full terminal, npm and more. It also runs entirely inside your browser ...

It appear this proposal is behind the curve compratively to both WebTransport and Google and third-party partnership experiments.

I filed https://github.com/whatwg/html/issues/3443 in 2018.

Google does what it wants. Then individuals and institutions follow.

thw0rted commented 3 years ago

I don't understand how running Node -- or any other software -- on an emulated virtual computer (similar to in-browser DOSBox) has anything to do with this issue, or the one you linked from 2018. Of course if the page is emulating an OS, it has full access to its "filesystem" and control over its operation. That's entirely unrelated to the security model of how the page is allowed to communicate over the network with services running on other origins (this issue), or an API for allowing the page to run arbitrary native code outside the browser (your link above).

guest271314 commented 3 years ago

From my perspective running Nodejs in the browser is for the purpose of achieving requirements that are not possible using the browser alone.

I have not invested time in the "security model" aspect of requesting resources from localhost. "Security" re networking is not really possible, certainly not possible to verify (A Good American).

The article says

WebContainers allow you to run a Node.js servers entirely inside your browser (including full CLIs)

which is what this repository appears to be focused on.

guest271314 commented 3 years ago

That's entirely unrelated to the security model of how the page is allowed to communicate over the network with services running on other origins (this issue)

I created a prototype working example of executing arbitrary native applications and shell scripts from any origin from a local server using existing web platform technogies (Transferable Streams, fetch(), window.postMessage() and printed the algorithm steps.

Start your local server. This can be done using a browser extension with Native Messaging.
Create an HTML document in the root of the server directory.
Turn off popup blocker at browser settings/preferences.
Open Window using window.open() with URL set to HTML document at 2.
postMessage() to opener from newly opened Window.
Transfer ReadableStream representing STDIN using postMessage() from opener to newly opened Window.
Read stream at newly opened Window.
fetch() localhost.
Transfer ReadableStream of Response.body representing STDOUT using postMessage() from newly opened Window to opener.
Read stream at opener.

guest271314 commented 3 years ago

@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?

Proof of concept https://github.com/guest271314/NativeTransferableStreams.

thw0rted commented 3 years ago

I think maybe you're on the wrong issue? Read the proposal linked in the original post (or at least skim it, it's pretty long). It sounds like what you're asking for is either the ability for the user-agent to understand platform-specific native scripting (bash etc), or better streaming APIs, or maybe both. That has nothing to do with this issue, which is about letting the browser communicate with the end user's home network safely -- think IoT devices, phones, printers, TVs, networking equipment. There are more examples in the use-case document.

guest271314 commented 3 years ago

That has nothing to do with this issue, which is about letting the browser communicate with the end user's home network safely -- think IoT devices, phones, printers, TVs, networking equipment.

Yes, this is the same issue. Yes, both. Your preliminary perspective as to relevance appears to be narrow, exclusionary, rather than realizing you cannot restrict usage to only the items listed in the posts you read. People will have use cases you have not considered, because they are individuals who can do what they want.

My use case is speech synthesis and speech recognition technologies, or anything else I decide to experiment with, using the same networking infrastructure.

The term "safely" is suspect. Again, there is no way for you to verify that claim.

I filed a use case issue https://github.com/httpslocal/usecases/issues/43.

guest271314 commented 3 years ago

It sounds like what you're asking for is either the ability for the user-agent to understand platform-specific native scripting (bash etc)

No. You misunderstand. User sends command from browser to a local server, local server sends back STDOUT which is streamed in the browser (see PHP passthru()), I achieved that win the proof-of-concept I linked to above, which meets the requirement of the use cases. The user can have any program, application, shell script, device, etc. they want on the local side.

My speech synthesis use case the input is can include an option to the program I am running, espeak-ng, which solves at least two outstanding issues in Web Speech API, the output is streamed as WAV to the browser, parsed to Float32Array's and set as source for a MediaStreamTrack, which can be further streamed to other peers and networks.

thw0rted commented 3 years ago

Ah, OK, I missed UC-04 in my initial read through, you're talking about Network-Based API. I was confused because all the other use cases are between a user-agent (browser) in one place and some service running on another physical device, on a local network.

Could you clarify what you mean about "safe" communication? The overall point of this proposal, as I understand it, is to come up with a standard for secure mutual authentication between the user-agent and a service on the local network. I believe the idea is to have it work sort of like Bluetooth pairing, where some shared secret is exchanged over a secure link when an association is first created, then the stored key is used to authenticate future transactions. What part of the proposed architecture seems unsafe to you?

guest271314 commented 3 years ago

Could you clarify what you mean about "safe" communication?

There is no such thing. One example: A Good American. The entire planets' signal communications was mapped and was capable of being intercepted and analyzed in "real-time" as of last century.

What part of the proposed architecture seems unsafe to you?

You can claim whatever you want. You simple have no means to verify that claim.

Thus, while individuals and institutions wantonly use the term "safely" and "secure", there is no way for you or them to verify that your signal communications are not being intercepted and analyzed.

guest271314 commented 3 years ago

The overall point of this proposal, as I understand it, is to come up with a standard for secure mutual authentication between the user-agent and a service on the local network. I believe the idea is to have it work sort of like Bluetooth pairing, where some shared secret is exchanged over a secure link when an association is first created,

WebRTC and WebTransport provide a means to do that, to an appreciable degree. See https://github.com/w3c/webrtc-encoded-transform, https://github.com/w3c/webtransport.

guest271314 commented 3 years ago

@thw0rted I implemented the means to turn the local server on and off from the browser here https://github.com/guest271314/NativeTransferableStreams/tree/main/native_messaging_local_server.

guest271314 commented 3 years ago

raveslave commented 2 years ago

some good ideas in the first posts any updates in this topic last 12m?

in the end "apple and google" needs to adopt/allow it in their desktop browsers... ...haven't followed the "matter" effort much, but feels like they forgot non cloud setups... i strongly believe that you must be able to do initial setup and use your hardware without limitations in a local, "non connected" environment.

guest271314 commented 2 years ago

@raveslave The requireent is possible using a browser extension; Native Messaging; and/or libdatachannel https://github.com/paullouisageneau/libdatachannel/issues/544.

Doesn't look like there is any movement in this repository.

httpslocal / proposals

A draft proposal for supporting local HTTPS communication. #2