Add solution to handle Chrome's new Private Network Access update

[MatinF]

Is your feature request related to a problem? Please describe.
Chrome recently introduced a Private Network Acccess update. One implication of this update is that it becomes more difficult to access self-hosted non-TLS MinIO S3 servers via public websites.

Specifically, our use case involves a set of end users that each need to self-host MinIO S3 servers with TLS disabled. The TLS needs to be disabled for some of our users who upload data to the servers through IoT devices, where non-TLS transfer may be preferred for speed and simplicity.

These users need to be able to login to their S3 servers via their browser from a public website. This works today as the users can open the public website via http:// in their browser and provide the login details for their self-hosted MinIO S3 server in a login screen. Through the Javascript S3 SDK, the tool can list files and perform various operations through the browser.

However, with Chrome's new update, this is now only possible in Firefox. In Chrome, it is no longer possible for the tool to be operated through the public website. Instead, users need to download the javascript tool to local disk in order to access their self-hosted S3 servers.

Describe the solution you'd like
The above challenge could be solved if there was a simple way to enable TLS access to the MinIO S3 server when trying to access it through a public website via the browser - while at the same time allowing the MinIO S3 server to run without TLS (which is necessary for the IoT devices).

One way presumably could be to run a non-TLS MinIO S3 server and then setup another MinIO S3 server with TLS enabled, which would serve as a gateway. Similarly, the challenge could probably be solved through NGINX.

However, what we were hoping to determine was whether a solution could exist that would simplify this, as either of the above can be overly complex for many end users.

[harshavardhana]

@MatinF unable to understand here if this is a MinIO issue or not. Are you just asking for suggestions?

[MatinF]

I was hoping that there might be some functionality in MinIO that could help resolve this challenge. If an existing solution exists, I was hoping that it would be possible to learn some steps to implement this - which might be added as a guide.

If no functionality exists, but something could be introduced, that would be ideal.

If this is the wrong place to ask this, I apologize - in that case let me know.

[harshavardhana]

I am not sure why you are thinking that IOT devices have challenges with TLS. Although for such devices the power consumption might be something to look for.

Using TLS in all situations is not a problem though, did you benchmark before with TLS and using non-TLS instead?

[MatinF]

We develop & ship the specific IoT devices in question. While TLS is a possibility to enable on these devices, it reduces the data transfer speed and adds complexity on both the IoT device and S3 server side.

One of the advantages of MinIO from our perspective is that it's so simple to set up that our end users can do this themselves. This means that they can deploy the MinIO S3 server, connect their device - and use our S3 browser tool in their browser to e.g. perform over-the-air updates, without having to set up TLS on devices or the server.

For many of our users, even just generating the public/private key needed in a self-signed certificate setup can be overly complex. Therefore we were hoping that there might be some alternative work-around that could be achieved via e.g. MinIO configuration variables.

In the ideal world, we'd be able to set it up so that an IoT device can upload data without TLS to the MinIO S3 server - while at the same a user can access the MinIO S3 server from the browser (using our public website tool) with TLS. As mentioned, we'd assume something like this could be achieved via NGINX or by deploying an extra MinIO S3 server as a TLS-gateway. However, these solutions introduce rather significant complexity into the setup for end users that may find this to be too difficult (to clarify, we do not host the servers ourselves, rather we guide users on how to set up their own MinIO S3 servers).

[klauspost]

Is there any problem in running reverse proxies to a non-TLS backend and have the proxy add TLS to one of the forwarded ports?

It is not something we designed for, just wondering if there is anything keeping it from working?

[MatinF]

@klauspost Yes, we believe a solution ala that should work - and it could probably be achieved via e.g. NGINX. However, we're struggling to find e.g. a GUI-enabled way of setting this up with ease for the end users (who may be relatively non-technical).

That was why we were hoping that something similar could e.g. be achieved "natively" within MinIO without having to deploy extra tools/proxies in parallel. For example, if it was possible to set this up via the MinIO Console GUI that would be ideal - but maybe it's a stretch...

[klauspost]

@MatinF That would require opening a second (third including the console) port. As I see it, that will add extra configuration options/confusion for MinIO, which I don't think is something we are willing to commit to.

Also, just want to mention that the AGPL license requires that all software connecting with MinIO be 100% open source for you/your users not to be in violation of the license.

[MatinF]

@klauspost Ok thanks for clarifying. And yes, the software in question is 100% open source.