Direct connection not working in chrome and edge

Hi,
The last couple of days chrome (and edge) have been connecting to my vera secure using the relay. Firefox on windows and the Samsung browser on my S9 works fine. chrome on my samsung and my lenovo tablet fails just like on windows.

I have tried to enable and disable “secure the connection” in the security settings, but no difference.

any suggestions?

-Anders

I get this in the console, so I guess that it has to do with chrome being picky.

Access to script at ‘http://192.168.1.20/cgi-bin/cmh/online_check.sh?tmp=1&noCacheIE=…’ from origin ‘http://home.getvera.com’ has been blocked by CORS policy: The request client is not a secure context and the resource is in more-private address space private.

I do connect to https://home.getvera.com byut when I click on the “connect” button it redirecte to a http:// address:
http://home.getvera.com/device/gotouihttp?xkey=
and from there It goes to the relay.

is there somthing I need to do, or is there something wron on the server side?

I entered a support request for this. (258485)
I beleive it has to do with chrome/chromium in newer incarnations is being picky about redirects from https to http.

And first line thinks my vera is unreachable. It is reachable, both locally and through the mios relay.

If someone reads this, i beleive this is the culprit https://developer.chrome.com/blog/private-network-access-update and Most likely this Private Network Access update: Introducing a deprecation trial - Chrome Developers

In case someone else is interested - https://web.dev/cors-rfc1918-feedback/#chrome’s-plans-to-enable-cors-rfc1918 had a reference to chrome://flags/#block-insecure-private-network-requests I disabled that flag, and now Chrome is back to doing direct connections.
this is the description of the flag:

Block insecure private network requests.

Prevents non-secure contexts from making sub-resource requests to more-private IP addresses. An IP address IP1 is more private than IP2 if 1) IP1 is localhost and IP2 is not, or 2) IP1 is private and IP2 is public. This is a first step towards full enforcement of CORS-RFC1918: https://wicg.github.io/cors-rfc1918 – Mac, Windows, Linux, Chrome OS, Android

So - for the moment, it is possible to get chrome to work as before, I have not looked at what edge does.
I can only assume that disabling “block-insecure-private-network-requests” is a temporary workaround, and that it will vanish when CORS-RFC1918 is fully implemented.

I also assume that this will make the Vera fully dependent on the mios cloud, for some of the UI actions (ie those where you have to be logged in)

@melih - I have no idea what your current plans for the “old” vera products is, but I hope that you have a different approach for logging in to the Ezlo products. CORS-RFC1918 is interesting, and wil most likely cause a lot of things to break, things that have been working for years-

we are constantly evaluating our security posture both at FW and Cloud level.

well, I hope that your staff will spend the time to make the necessary adjustments, and make the logins via home.getvera.com able to use the direct connection.

and that you make some sort of statement if not (in the form of a security enhancement announcement, as the veras don’t support https…)

Thank you for doing all of this research. I will give this a try

1 Like

Thanks so much for figuring this out. It’s been driving me crazy and I reported it to Vera Support with no clear answer.

I disabled the “Block insecure private network requests.” option, and direct connect started working again in Chrome.

Please note that the workaround will stop working in may 2022 when chrome 102 is released, and that edge us sffected as well.

This is my final reply to 1st level support in my support issue (258485) on oct 19. @melih It saddens me to learn that 1st line seem to be unaware of the issue. It will not go away.


Note that according to the chrome/chromium time plan, the flag to disable the new behavior will be deprecated with Chrome 102

  • May 2022: Chrome 102 rolls out to Stable. The deprecation trial ends. Chrome blocks all private network requests from public, non-secure contexts.

(This is from https://developer.chrome.com/blog/private-network-access-update/)

I also checked (in case any customer asks) – the flag is available in Microsoft Edge as well, and it is reached through edge://flags/ (search for insecure)