httpslocal / usecases

discussion about use cases
Other
18 stars 11 forks source link

Collect use cases #1

Open tomoyukilabs opened 7 years ago

tomoyukilabs commented 7 years ago

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

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

Corrected.

ecorm commented 6 years ago

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:

tomoyukilabs commented 6 years ago

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

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

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

dajiaji commented 6 years ago

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

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

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

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

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

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

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

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

Use case:

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