Hi
Is there a way to connect to the Player / Server (Antipodes K50) that is secure from the perspective of Chrome?
As you can see from the image - Chrome is not happy with the local connection and this has a knock on effect - such as needing to tweak settings so that popup are not blocked - in this case configuring a soundcloud connection from Squeeze.
Ideally the connection on the local network should look more like the connection to the Antipodes support site?
It doesn’t appear that there is as https isn’t available. In this case though it is unnecessary. Secure in this case means that the connection is encrypted. There is no information passed to or from the AMS dashboard that needs to be encrypted.
You are in a trusted internal network when using AMS, https isn’t required.
When connecting to our website you are outside of your local network, https is used.
I appreciate the nuances of local and external networks.
However my Browser does not necessarily compute those differences and consequently queries what it is being presented with - a website address that doesn’t have all the usual conformity that an Internet facing address needs to have.
As I also suggested some of the functionality such as enabling the squeeze session to go off and do an API token exchange with Soundcloud were complicated by Chrome shutting down some of the normal functions of a web page (such as opening pop up windows)
Is it simply a set of trusted certificates missing that is creating the issue or something more?
I am curious as if its a easy fix - happy to tinker around.
Many thanks
There is no set conformity for internal destinations. The configuration pages for both my router and NAS behave the same way as AMS. Unencrypted connections over http are quite common in home networks.
Which makes sense when traffic sent between destinations are kept internal. When however applications are launching external connections to third party sites (as was the case with configuring the SoundCloud account in Squeeze) that is less ideal. Consumer domestic networks are less the focus of nefarious actors than corporate or public networks - but risks remain. I would suggest that there is no conformity in consumer internal networks. In the corporate world of east-west networks the concept of zero-trust is well documented
Browser encryption only ensures that communications between the browser and backend application are protected from man-in-the-middle attacks. Communications between an application and an external endpoint would have to be independently protected. Squeeze itself is likely establishing between itself and SoundCloud over a secure/encrypted connection.
Said in a less technical way, when one inputs credentials into Squeeze page, communication between one’s browser and the Squeeze app isn’t encrypted. A smart hacker who has access to one’s home network could potentially snag those credentials at the moment they are posted to the app. Infinitesimally low risk.
Browser encryption plays no role in subsequent interactions between Squeeze and external destinations. Secrets are likely passed only in a secure way.
