How to enforce HTTPS

What is the best way to enforce HTTPS access to Nextcloud.
Currently I use a combination of the app “HSTS Header” and a rewrite rule in .htaccess. However, I am not yet satisfied with this.

The HSTS header forces the client (browser) to perform all access to Nextcloud only via the https protocol. But since the HSTS header is only added on https responses, this only works after the first https access to Nextcloud. Any previous http access will be processed without security.

In addition, I force the web server (Apache, Linux) to replace each http access by a corresponding https access. The rewrite rule required for this in the .htaccess file has often be discussed in the community. Unfortunately, however, many software updates (upgrade Nextcloud to next version) replace this file. So you must always remember to check this file and re-enter the rewrite rule. It does not help if you enter this rule after the line
"#### DO NOT CHANGE ANYTHING ABOVE THIS LINE ####".

Is there a better, more elegant way?

Regards,
Friedbert

Hi @Friedbert

I would not do it in the .htaccess file. Are you sure the rewrite rule in the .htaccess file is even processed. It seems to me the redirect / rewrite is not working at all. Thats’s why it only works in the browser that already once connected successfully via HTTPS.

I use an Apache VirtualHost with the following config…

<VirtualHost *:80>
Servername cloud.mydomain.tld

RewriteEngine on
RewriteCond %{SERVER_NAME} =cloud.mydomain.tld
RewriteRule ^ https://%{SERVER_NAME}%{REQUEST_URI} [END,NE,R=permanent]
</VirtualHost>

It rewrites every HTTP request for cloud.mydomain.tld to HTTPS.

Hi bb77,

Blockzitat

Yes, it works! Until the file is replaced again during the next software upgrade.

C:\Users\Fried> curl -i http://cloud.mydomain.tld
HTTP/1.1 301 Moved Permanently
Content-Type: text/html; charset=iso-8859-1
Content-Length: 240
Connection: keep-alive
Keep-Alive: timeout=15
Date: Mon, 24 Jan 2022 19:24:06 GMT
Server: Apache
Referrer-Policy: no-referrer
X-Content-Type-Options: nosniff
X-Download-Options: noopen
X-Frame-Options: SAMEORIGIN
X-Permitted-Cross-Domain-Policies: none
X-Robots-Tag: none
X-XSS-Protection: 1; mode=block
Location: https://cloud.mydomain.tld/

Thank you for this suggestion. Unfortunately my hosting provider does not allow to change the Apache configuration files.

Regards, Friedbert

And in the admin panel of your web hoster is no setting availabe, where you could enable permanent redirects for your sites? If not, I unfortunately do not know any other solution either, except of just manually re-adding the rederict after each update…

…or changing to another hosting company. :wink:

I don’t see why doing this in the htaccess file is a bad way to do it. Wouldn’t any automated process in the control panel would simply accomplish the task by updating the htaccess file, anyway? For now, my own installation is on a shared hosting account, and I also have run into the problem that forcing https through cPanel is not available. They claim it’s a cPanel bug, which I’m not sure I believe. But regardless, changing hosting companies simply to appease a Nextcloud bug does not seem like a reasonable solution.

Those points aside, I think that there is a broader solution that should be implemented. In two recent installations I noticed that after setting HSTS header, that information was deleted when I ran the occ update htaccess command. Which is kind of a silly thing to do. It seems to me that the mentality is all wrong from the outset. Replacing or overwriting the htaccess file is a lazy approach. Requiring manual tweaks to be universally implemented is silly. Why is the HSTS header not included in original htaccess file from the outset?

I’m not an expert when it comes to cpanel or other management tools for web hosting. But I would guess, that cpanel would do it in the in the respective Apache VirtualHost, to which you have no access, respectively only to the settings that are made available to you through cpanel.

Or it is simply because your hoster do not provide you with your own Apache instance, but only with one VirtualHost and a limited feature set.

You can call it a bug. The Nextcloud devs would probably call it a feature. :wink: Nextcloud is not just a simple website. It is a complex application that runs best on it’s own dedicated server with is own web server instance and database etc… which then should be optimezed for Nextcloud. You can run it on a shared hosting platform. But you will always be somewhat limited, depending on what kind of hosting platform you use and what functionality the hoster provides you with.

The broader solution would be using a dedicated web server or at least a dedicated VirtualHost for Nextcloud. Of course that’s not possible with a single shared webhosting account, that has limitations like this so called cpanel bug.

I think the Nextcloud devs do not primarily have shared web hosting platforms in mind when they develop the software. It would certainly not be impossible to integrate such a functionality directly into Nextcloud, so that even users who don’t have administrative access to the web server could easily manage such settings on application level. In theory it would even be possible to integrate this into the WebUI. But I think the devs have other, more important issues they should address :wink: But feel free to create a feature request on Github.

hold your horses, mate as this marks NO Nextcloud bug at all.

of course you could change it there. But as far as I remember it ended up in some confusion where exactly to make neccessary changes. So it was a mutual decision to make the changes in apache and NOT in .htaccess. You could search the forum for more detailed information.

Pls keep in mind that NC was first and foremost not made to be used with shared hosters.

1 Like

Of course, it’s not a bad way to that. That’s exactly how I’m doing it at the moment.

It only becomes dangerous when these settings are deleted again without informing the system administrators. This can happen with every upgrade of the Nextcloud software.

Then an unaware user can enter the server address without scheme (cloud.domain.tld) into a browser and ends up on the login page with the unencrypted http protocol. When logging in, his user data is transmitted unencrypted over the Internet.

I wish that customizations in the .htaccess file are preserved across software upgrades. I can imagine this in different ways. For example,

  • the upgrade process can update only the part of the .htaccess file that precedes the marker line
    #### DO NOT CHANGE ANYTHING ABOVE THIS LINE ####
  • Alternatively, it could be a small app where you can enter additions to the .htaccess file (similar to the app Custom CSS). But here you have to make sure that these additions are taken over into the new .htaccess file directly during the software upgrade.

Regards, Friedbert

That may be so.

Nevertheless, we may think about how to extend Nextcloud so that it can also be operated securely on such platforms.

A change to a dedicated server is not feasible for financial reasons. The only option would be to switch to another cloud software.

Regards, Friedbert

You could think about installing the hsts app: https://apps.nextcloud.com/apps/hsts

1 Like

But now that you know that, you also know how to midgate the risk. Just check if the config is still there after an upgrade, and if not, insert it again. Should not cost you more than one or two minutes extra time

Wich of course isn’t really free either. If you use more than 10GB with for example Google, you have to pay. There are VPS offers for less than 10€ a month that offer more than 10GB of storage. And there are also hosted Nextcloud providers. If hosted on a web hosting platform, your data is in the “cloud” already anyways, why not switch to a dedicated Nextcloud hosting platform?

You should read my initial comment.

So it still happens that the credentials are transmitted unencrypted.

Regards, Friedbert

The HSTS Header is just an extra layer of security. It is not suposed to redirect anything, it is supposed to block none HTTPS connections to a certain domain or subdomain. And of course this relies on external infrastructure and on your browser knowing that it has to block HTTP to a certain site. I can not explain in detail how it works, but thre are plenty of articles in the internet about that topic. Anyways…

A HSTS header and a redirect have to be in place if you want to be sure that users can connect through HTTPS without explicitly add HTTPS to the URL, or that no one will be able to connect with a plain HTTP connection. And if it isn’t possible, for whatever reason, to add the redirect and HSTS header directly to the configuration of your web server / VirtualHost, the only way to do it, is using the .htaccess file. And yes that means, that you have to check and maybe re-add these lines after an upgrade of your Nextcloud.

1 Like

Really? So you think that overwriting someone’s htaccess configurations is a good idea? Of course it’s a bug! Nextcloud should not be overwriting data in the htaccess file, and it should not
be replacing htaccess files every time it updates. That is just lazy, bad procedure.

Uh, what? You’re entirely off base here. You make it sound like Apache only exists to implement Nextcloud. In essence, you’re demonstrating my objection, which is that Nextcloud should not require a web server that is subservient to it, instead Nextcloud should be designed to function when subservient to the server.

Imagine if I were to install a program on my laptop, but the program was so delicate and tempermental that I had to reconfigure my entire operating system just to appease the program. The problem would not be in the OS, but in the program. The same is true here.

The question here is how to enforce https. This is not actually a Nextcloud issue. It is a general website building issue. So the solution cannot be Nextcloud specific. Except that, in this case, Nextcloud ends up requiring a Nextcloud specific solution because Nextcloud itself destroys the configuration. That is, without a doubt, a bug.

You and BB both say this as if it’s a strength, when in reality you’re simply appealing to weakness. In your world, Nextcloud would not only need to be on a dedicated server, it would need to be on a very specifically configured server. In fact, we may as well go a couple steps farther and do away with enabling people to download and install Nextcloud at all and simply ship them hardware that’s been manually coded in binary. Heck, maybe even through in a few vacuum tubes for good measure.

Or, maybe Nextcloud should catch up with the rest of the 21st century.

I want to take a moment to further point out that in all this talk about virtual hosts and dedicated servers and htaccess configurations, it is being clearly ignored that Nextcloud itself uses an htaccess file in the root directory. And if Nextcloud is meant to only be installed on a dedicated server, then why does Nextcloud bother to create or us an htaccess file? Why not simply instruct the user to implement all settings in the httpd file, and be done with it? After all, the pure reason for using an htaccess file is for directory specific rules.

If you all really believe what you’re saying, then it’s all the more reason why you should frown upon Nextcloud making changes to the root htaccess file that the user did not explicitly perform.

There is no point in splitting hairs here. It does still work on shared hosting platforms after all. Your specific issue regarding the .htaccess file was discussed and then they decided to do it that way. You can probably find the discussion on GitHub. Feel free to open a new issue if you disagree or want them to change that behaivour.

You’re not completely wrong… But If anything feels like the 1990s, it’s LAMP Stacks and hosting PHP apps in subfolders of a shared host with .htacces files :wink: Btw… Owncloud is working on a Go implementation of their software. That would be 21st century all the way, but it would definitely no longer work on a LAMP stack. :wink:

I could enable https redirects in cpanel years ago (not sure about HSTS) when I still used shared hosting. Maybe you should find a hosting provider that does the job right. And, you already spent more time complaining about this minor issue, than you will ever need for checking and correcting the .htaccess file during the next 10 Nextcloud upgrades. Just sayin’ :wink:

1 Like

we could state that the tone of this one specific reply was inappropriate.
topic closed because everything was already said.