Cloudron Forum

Hi there,

Lately, there seems to be a swath of people (outside of Cloudron, at least) reporting their PDFs no longer get thumbnails generated. I recently had to force regenerate all thumbnails on one of my WP sites on Cloudron, and faced the same issue: PDFs no longer get thumbnails.

While investigating, it seems that ImageMagick could be the culprit here. I think WordPress uses ImageMagick to do the conversion. Using wp media regenerate outputs lines like:

Warning: attempt to perform an operation not allowed by the security policy `PDF' @ error/constitute.c/IsCoderAuthorized/408 (ID 5110)
Warning: No metadata. (ID 5110)
3/558 Couldn't regenerate thumbnails for "<redacted>" (ID 5110).

I traced it to the /etc/ImageMagick-6/policy.xml file that must've changed recently in the base image used by Cloudron. Could you perhaps look into it? I'm using PDF thumbnails heavily on one of my hosted sites and it used to work just fine

Thanks in advance!

All the best,
Vince.

@nebulon Like I said, I thought it would be an issue for a particular client, but it's not!

However, only as long as the config stays as it is; if you ever strengthen it by adding the "includeSubdomains" directive in the HSTS header (as it is advised sometimes in some of the readings I found for better security), you could cut access to subdomains that are not managed by Cloudron and cannot do TLS.

The typical fictional scenario, if the config ever changes, would be:

• www.watering-plants-automatically.cloud is a website from a company that offers to manage clients' gardens; the designer of the website hosts it on its Cloudron instance for the client.
  The company already has stuff they host on subdomains, and won't relinquish access to the DNS server for security reasons. However www and the root domain both point to the Cloudron server IP, so Let's Encrypt works fine in "Manual" mode in the Domains & Certs tab of the designer's Cloudron;
• An end-user visits the website, decides to sign up and pay for their new fangled tool, which is hosted at myplants.watering-plants-automatically.cloud. This subdomain points to the IP of the appliance that manages the users' gardens. This is an old, crummy box that won't allow TLS, because it's almost an antic at this point;
• The user cannot connect to their tool, and throws an HSTS error.

It's not an issue yet, but it might be something to think about if you ever consider changing the configuration (let's say, if you decide all domains with a wildcard cert should have includeSubdomains in their HSTS headers).
Security-wise, it makes a ton of sense: let's say you type http://www.domain.tld in your browser.

• The server 302s you to https://www.domain.tld which has the HSTS header and "includeSubdomains"
• You later type http://mail.domain.tld in your browser: the browser will immediately connect to https instead, avoiding potential MITM attacks.

Pretty powerful, but it might be an issue in this particular case where some subdomains shouldn't be covered.

I initially thought I read in the docs that the HSTS config was such that all subdomains were included, and I remember that before using Cloudron, for this specific client, I set the header to "includeSubdomains", which promptly disallowed access to many tools I do not host because they didn't support TLS on them, if the user visited the main website before.

So yeah, feel free to close that topic, because it's not an issue unless you decide to change the config server-wide

Hey @girish,

It's for existing subdomains, not managed by Cloudron, going to appliances that do not support TLS. Still happens in enterprise settings, even though I shudder at the idea!

Ideally, I'd like to see a switch, perhaps in an "Advanced" tab, to disable HSTS if need be; if you ever implement the "includeSubdomains" directive in the HSTS header for better security, or if browsers decide to implement HSTS differently, I'd like to be able to not kill access to systems I'm not managing on other subdomains.

I guess I jumped the gun a little opening this support thread, as Cloudron does not send the includeSubdomains directive; but it's something to consider when you host, say, a corporate website on www and the root domain, but host an appliance that does not do TLS on a subdomain. No issues as of now, really, but something to consider if you ever change the config!

Thanks!
Best,
Vincent.

Hi,

I was wondering if it's possible to selectively disable HSTS on certain apps. I host a website for a client who has a few services on subdomains that do not do TLS (I know it's bad, but I only host their corporate website), so HSTS makes them inaccessible, since the website is on the root domain.

Is it at all possible? I know it's weakening the whole "secure by default" mantra of Cloudron, but it'd be nice to see! Perhaps in a config file somewhere instead of a switch in the interface, this way you won't have droves of Cloudron users disabling it without understanding why.

Thanks in advance!

Best,

Vincent.

@girish That's awesome news! Looking forward to v6.0 then!

Keep up the awesome work

Hello,

I'm wondering if it's possible to tweak the settings in tls.ini for Haraka. A client of mine has a corporate firewall in front of their self-hosted Exchange server, and I cannot send mail to them.

I do not know which platform they use, but it's self-hosted. All I know is that Gmail accepts my mail, so does Protonmail. Outlook does not, but it's because it's a recently installed server from OVH, and as such the IP is blocked until further action (which I started). I used to use Plesk for years on another server, and mail ended up in spam on Gmail ; this time, it's even in my inbox, even though the domain is two days old and the IP has never really been used for email. I'm in no DNSBL, as well.

In the meantime, is it even possible to tweak the available curves? I know Haraka allows it, but searching the filesystem for the tls.ini file yields only stuff in Docker overlays, and I don't know which one to edit. I'm fairly certain that editing that file by hand will yield nothing, and get erased by the default one next time I do anything that needs the container to rebuild, unless I'm mistaken.

Thanks!

Best.