[Website] Missing HTTPS

[polarathene]

Just visited the website and noticed the "Not Secure" label in the URL bar, tried https:// but it failed. Is there any reason the website isn't served over HTTPS?

[phillxnet]

@polarathene Thanks for the report.

We do hope to add https to the site when time permits but we also run a number of other services that all Rockstor instances use from this same Apache instance and domain, such as Rock-ons, and some legacy updates, so we have to tread carefully, but this is planed when our sys admin time becomes available to focus on this. But alas we have some more pressing matters ahead of use before that. But we should get there eventually and I'm due to update the web page itself soon so hoping I can take another look at these interdependent configurations while in that area.

So in short the answer is human resource availability, nothing more; hopefully. But for the sake of a https on an open site where there is nothing sensitive exchanged where the content is neutral I don't want to do a rush job and break all Rockstor installs.

Linking to an existing forum post on this same issue:
https://forum.rockstor.com/t/website-not-https/7187

Also, as an aside, I hope to soon release a GitHub repo of the site so we can then move this issue to that side as it doesn't relate the rockstor-core code as such, but would at least have a closer relation to the website repo. We can then entertain community contributions and translations of the main site which will be nice.

Hope that helps.

[polarathene]

But for the sake of a https on an open site where there is nothing sensitive exchanged where the content is neutral

Yeah, no worries, it's unlikely anyone is going to exploit the site with a direct MitM attack, worst that would happen is third-parties injecting content like ads, but that's usually over wifi out of the home (where I can't imagine Rockstor is popular to visit on the go).

There is one other reason beyond authenticity and encryption concerns, if your website ever needs to use any of these features, they require HTTPS. Only ones likely of value to Rockstor would be service workers or the cache-control header (as and additional minor optimization). A few others like HTTPS/2 and Brotli are also non-critical nice to haves that require HTTPS.

But mostly, you avoid the "Not Secure" label in browsers, it might be a minor enhancement, but it's valid red flag when it comes to trusting a website/service due to the low effort to support HTTPS in the browser these days.

we also run a number of other services that all Rockstor instances use from this same Apache instance and domain, such as Rock-ons, and some legacy updates, so we have to tread carefully

Consider placing Traefik or Caddy in front. They're relatively simple to configure if you have multiple services to support and require some remain HTTP, while anything that is fine with HTTPS can leverage the automated LetsEncrypt support, which I suppose isn't as maintenance free with Apache?(I don't have much experience with it)

I don't want to do a rush job and break all Rockstor installs.

Is there a reason they wouldn't be compatible with HTTPS? Either or you could use a reverse proxy to use HTTP with no redirect for whatever URL route they require, while keeping everything else over HTTPS.

I hope to soon release a GitHub repo of the site so we can then move this issue to that side as it doesn't relate the rockstor-core code as such

That'd be great :) I did try to look for such a repo before. If your website doesn't need any backend to work, pairing a Github repo with Netlify or Vercel is really nice. When you merge changes to master branch, an automated build and deploy (optional) is run, hosting for such shouldn't add any additional costs, you'd just point the domain to that service and you're sorted, they'll handle HTTPS certs for the site then. That assumes your other services use different domains or subdomains.

So in short the answer is human resource availability, nothing more
alas we have some more pressing matters ahead of use before that.

All good, I understand how that it is 👍

[phillxnet]

@polarathene Thanks for the pointers. Nice.
Re:

But mostly, you avoid the "Not Secure" label in browsers,
Agreed, this is a bad show on our part.

Is there a reason they wouldn't be compatible with HTTPS?

I hope not, as otherwise we have further complexity which is exactly what I'm trying to avoid. Well that and maintenance overhead.

That'd be great :) I did try to look for such a repo before.

Yes, hopefully soon. I really like the idea, given we are a community project at heart, that folks can chip in with main page content via pull requests. I'll get there, and hopefully soon. Plus I want to field for translations on the main page. And once I've got the move to a static site generator sorted (Looking a Hugo currently) that should all become a lot easier.

That assumes your other services use different domains or subdomains.

Are yes, the tricky bits are always in the details. Some do and some don't unfortunately. Our forum is lets Encrypted and on it's own subdomain, and our newer update repos are also on their own subdomain but the rest isn't unfortunately. But again, just needs a bit of careful attention and we will get this one sorted. It does bug be that we are not quite with the times on this one. But our main Rockstor Web-UI does use https, all-be-it with a self signed certificate. But better than nothing. And we also have a subscribers only facility that is also https lets encrypt. It's only really the main page and docs that are letting the side down here.

Thanks again for the pointers. But few I find mention the global effect of all that encryption/decryption on every single page view when the majority are entirely without need of it. Oh well. Injection angle was interesting, hadn't considered that one. Times are a changing I guess (waving old man stick) :) .

[StephenBrown2]

maintenance overhead.

Maintenance is minimal to non-existent with an ACME client (Like Caddy Server or Certbot or numerous others) auto-renewing certs from something like Let's Encrypt, which I'm sure you've seen on your forum and the subscribers only facility.

few I find mention the global effect of all that encryption/decryption on every single page view when the majority are entirely without need of it.

I DDGed "https encryption is expensive" and "https encryption is slow", and found several pages saying exactly the opposite, rather that the overhead exists, but is minimal:

• https://blog.cloudflare.com/how-expensive-is-crypto-anyway/
• https://istlsfastyet.com/
• https://sslrenewals.com/blog/top-5-encryption-myths-debunked
• https://wp-rocket.me/blog/https-affects-website-performance/
• https://www.keycdn.com/blog/https-performance-overhead

I'll offer to help get all the things on to HTTPS via Let's Encrypt, since I know that manpower is the scarcest resource, and reading yet another comment without an offer of assistance is only a drag on your time.

[phillxnet]

@polarathene, @StephenBrown2, & @FroggyFlox I've begun working on this issue:

We should now have a parallel https feed of all services from this server.

No http->https permanent redirect just yet as still some more checking to do, but I intend to add that soon: post more research/testing on potential adverse effects re rock-on repo & the old rockrepo (early CentOS varaint).
See the following forum thread for context & related services: https://forum.rockstor.com/t/rockstor-com-maintenance/7847

I'll close this issue once we have the re-direct in place and all is well there-after.

[phillxnet]

@polarathene, @StephenBrown2, & @FroggyFlox

Permanent redirect (301) on http -> https now in place for entire web server config. Please see the folloowing forum post for the tests I used to ensure we have continued & expected function from this server:

https://forum.rockstor.com/t/rockstor-com-maintenance/7847/5

Re:

I'll close this issue once we have the re-direct in place and all is well there-after.

If I don't hear anything untoward relating to this http -> https transition and consequent redirect I'll close this issue shortly.

We can always re-open if something crops up that I've missed.

On a related note, we now have roughly twice the number of calls to this site! What with all the redirects. Unavoidable I guess, and it should reduce as folks start to use the likely favoured https links.

[polarathene]

From the linked forum post:

On a side note we might want to enable server side compression (with caching hopefully) to gain back some of the bandwidth/load we may have lost here. But this is material for another forum post/GitHub issue.

Is that referring to brotli and/or gzip? If so 👍

I wouldn't expect the HTTP redirects to be contributing much bandwidth/load impact?

To reduce the number of requests, when you're more comfortable/confident with HTTPS setup; you could look into using HSTS headers and submission to browsers to better enforce HTTPS over HTTP?

Cache-control headers would probably be good yes :)

[phillxnet]

@polarathene , @StephenBrown2
Re:

I hope to soon release a GitHub repo of the site

&

That'd be great :) I did try to look for such a repo before.

Now sorted: https://github.com/rockstor/rockstor-website

And as we've had no reports of issues thus far re this http -> https move I'll close this issue. Some mixed content hard-coded in the site code but I've opened a specific issue in the new repo for that anyway. Not a show stopper but at least we have it issued for now. Ended up sorting this https move prior to the above new GitHub repo and this move was down mainly to server config anyway so didn't really have a proper home re GitHub repos.

Also

Plus I want to field for translations on the main page. And once I've got the move to a static site generator sorted (Looking a Hugo currently) that should all become a lot easier.

See issue 1 in the new repo: rockstor/rockstor-website#1
"Migrate to Hugo"

Bit by bit. And thanks for our patience / encouragement on this one. Nice to get this sorted before our Rockstor 4 "Built on openSUSE" re-launch.