koush / ha_scrypted

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Addon should not enforce SSL

mister2d opened this issue · comments

Please allow the add-on to use HTTP or HTTPS endpoints.

Use case:

  • When containers are run in a sidecar based service mesh, SSL/TLS is taken leveraged at that level.
  • Home Assistant runs on the Alpine base container image. If one did use an external HTTPS endpoint using the FQDN, you will run into the ndots issue.

@koush I run scrypted NVR with 8 cams in Kubernetes and this affects me, I cannot connect my Home Assistant to scrypted. Any way you could add support for just a url and not do the port parsing and enforcing https?

@koush I run scrypted NVR with 8 cams in Kubernetes and this affects me, I cannot connect my Home Assistant to scrypted. Any way you could add support for just a url and not do the port parsing and enforcing https?

This sounds like a configuration issue. Make sure the correct ports are forwarded/exposed. 10443.

@koush I run scrypted NVR with 8 cams in Kubernetes and this affects me, I cannot connect my Home Assistant to scrypted. Any way you could add support for just a url and not do the port parsing and enforcing https?

This sounds like a configuration issue. Make sure the correct ports are forwarded/exposed. 10443.

Not exactly. As mentioned in the issue, the default configuration is used. In my environment there also isn't a need to forward or expose ports.

What's happening is that the code is enforcing https when the scheme should be configurable (http:// or https://):

f"https://{ip}:{port}/login",

url = f"https://{ip}:{port}/{quote(path)}"

Also, implicitly trusting any certificate no matter the signer presents a security issue and isn't best practice:

@koush I run scrypted NVR with 8 cams in Kubernetes and this affects me, I cannot connect my Home Assistant to scrypted. Any way you could add support for just a url and not do the port parsing and enforcing https?

This sounds like a configuration issue. Make sure the correct ports are forwarded/exposed. 10443.

@koush it’s not a configuration issue. I run Scrypted inside the cluster on 11080 and on HTTP. I want to be able to input a url with scheme and port for the HASS integration.

Enforced SSL makes no sense especially when Scrypted runs on a local network and remote access only taking place via Scrypted Cloud. I also had to realize it also makes it impossible to proxy pass for embedding feeds and clips into any advanced contexts with other services (e.g. dashboards). I don't even want to open the browser console with all the critical error it reports because of SSL issues. I wonder what makes this a requirement.

There are a ton of web standards that scrypted uses that requires a secure context. Disabling https is a nonstarter.

https://developer.mozilla.org/en-US/docs/Web/Security/Secure_Contexts/features_restricted_to_secure_contexts

There is an insecure endpoint available, but it is only there for webhook purposes.

Terminating http with https can be done if the proper forwarding headers are supplied.

The custom component will also proxy scrypted behind HA, so a lot of this is moot anyways. Secure Context restrictions still apply.

Well, I still don't get it. Other scripts do not need this and it comes up as possible source of error everywhere, even if it might not be directly involved. For instance, I am now trying a new Home Assistant setup running on VMWare Windows, while running Scrypted Desktop on the same machine in parallel. Both HA in VMWare and Scrypted Desktop work flawlessly on their own, but for some reason I am failing to connect HA with the Scrypted Desktop instance, always receiving an "Unknown error occurred" message.

image

Upon looking into the HA system logs for possible causes, guess what I find:

image

I have no clue whether this is actually whats causing the error, but I feel any error with Scrypted has a high likelyhood to be SSL related, especially considering anything else on HA runs without certificates.

please refrain from opening new issues on this. supporting insecure contexts will just result in a different class of bugs being opened (on the main project and related projects) regarding the aforementioned limitations of insecure http contexts.
I do not want to create any dependencies on the http endpoint, because it may very well be removed completely.

the choices made were to limit support issues. other projects may make other choices, as they have different requirements.