Collect use cases

[tomoyukilabs]

we would like to collect use cases where browsers communicate with web-server-capable via HTTP and/or WebSocket over TLS, for the purpose of clarifying network and security requirements. Summary of TPAC breakout session would be useful to understand why considering use of HTTPS/WSS seems to be necessary for devices in local network.

If you find another use case, please submit a Pull Request to add it to UseCases.md, or add your comment to this issue.

[igarashi50]

I think that the above link "userCases.md" is missing. The link should be changed as follows.

(Original) https://github.com/httpslocal/usecases/issues/UseCases.md (Change) https://github.com/httpslocal/usecases/blob/master/UseCases.md

[tomoyukilabs]

Corrected.

[ecorm]

Not exactly use cases, but here's a list of LAN-connected consumer products that do (or could) provide a browser interface to their users:

• Network routers
• VoIP base stations
• Printers
• Network-Attached Storage
• Smart thermostats
• Home automation gateways/controllers
• Weather monitoring stations
• Video surveillance equipment
• Baby monitors
• Media centers and PVRs
• Refrigerators

[tomoyukilabs]

@ecorm LGTM. I'm happy with these good suggestions.

We can still add an additional use case that has not been technically covered in the current UseCases.md. At least, I'd like to check if there would be any technical gap between the current use cases and the products listed above.

@dajiaji @igarashi50 Any comments or thoughts?

[RichardTea]

One scenario that is not covered is a private LAN that has no connection to the general Internet.

This is very common in industrial automation. The user wishes to securely monitor and control devices incorporating HTTPS servers from anywhere within this private LAN, but does not require remote access and does not wish to connect to the general Internet.

The desire for HTTPS is to prevent unauthorized users that may gain physical access to this LAN from also gaining access to the industrial devices, and to prevent same from 'spoofing' the industrial devices.

At present, these networks tend to completely rely on physical security, which has obvious limitations.

[ecorm]

FYI: https://owaspsummit.org/Working-Sessions/IoT/TLS-for-Local-IoT.html

[dajiaji]

@ecorm Thank you for the information. Good to know that there is an activity that has the same purpose as us. I think TLS-SRP can be one of the candidate solutions for HTTPS in local network, too. We will add the information to RelevantSpecs.md and other related documents. Thanks.

[daniel-kun]

You already have the home-automation use case on the list, but I'd like to reinforce this aspect.

Currently, many home automation providers - be them open source such as home assistant/iobroker, or consumer gadgets like Nuki, Nest, Alexa or professional solutions (I know a few very large, German home automation manufacturers that are affected) - only allow HTTP connections, or allow HTTPS connections and take into account that the user will be presented a very dangerously looking warning by the browser (when accessed by a human) or implement HTTPS security only partially (when accessed by another machine).

I think this is very unfortunate, and it's harming the "Smart Home" scenario as a whole, and I'm glad that you are working on changing this. Btw: I've written a blog post with some insights, ramblings and proposals here: https://dev.to/danielkun/where-is-https-for-iot-49ao

I'd be glad if you could provide you with further information regarding requirements in smart home / IoT scenarios, if required.

[daniel-kun]

FYI: https://owaspsummit.org/Working-Sessions/IoT/TLS-for-Local-IoT.html

@dajiaji Unfortunately, this host does not seem to be available, anymore. (ERR_CONNECTION_TIMED_OUT)

[dajiaji]

@daniel-kun Thanks for your comment! Your point is one of the reasons why we formed the Community Group. Since our use case document has not been completed yet, we'll end up refining the document sooner or later.

Btw: I've written a blog post with some insights, ramblings and proposals here: https://dev.to/danielkun/where-is-https-for-iot-49ao

Thanks for sharing. It's a great, exhaustive work. I'm thinking about the solutions similar to your proposal 1.a. and 2. Especially, I strongly agree with your following opinion.

the manufacturer should be the instance that knows best how to check the device for authenticity. So why not let the manufacturer do this? Browsers could implement a mechanism following this scheme ...

[dajiaji]

FYI: https://owaspsummit.org/Working-Sessions/IoT/TLS-for-Local-IoT.html @dajiaji Unfortunately, this host does not seem to be available, anymore. (ERR_CONNECTION_TIMED_OUT)

Oh, sorry but it's uncontrollable for me...

[Zenkibou]

FYI: https://owaspsummit.org/Working-Sessions/IoT/TLS-for-Local-IoT.html @dajiaji Unfortunately, this host does not seem to be available, anymore. (ERR_CONNECTION_TIMED_OUT)

Oh, sorry but it's uncontrollable for me...

I think that this could be the source: https://github.com/OWASP/owasp-summit-2017/blob/master/Working-Sessions/IoT/TLS-for-Local-IoT.md

[Zenkibou]

It has already been mentioned, but I still don't see a use case where the font page is fetched locally instead of from internet.

Maybe a NAS would be a good use-case for this ?

[daniel-kun]

@Zenkibou You don't want to be unable to print when the internet is down, do you? :-) I think this holds true for any IoT device, be it a printer, a NAS, a smart home controller, a smart speaker, ...

[guest271314]

Use case:

• Execute arbitrary native applications and shell scripts.
• Speech synthesis and speech recognition streaming.

I cobbled together a prototype using existing web technologies if this body is interested.