Display correct error message if some self checks could not be performed due network timeout to overwrite.cli.url

[Somebodyisnobody]

Tested on Nextcloud 31.0.4.
My setup: Nextcloud standalone in a debian machine behind a reverse proxy.
Initial situation: During an upgrade I always block incoming requests (except my admin machine) via firewall on the reverse proxy. After the update I look for the self check in /index.php/settings/admin/overview for errors and warnings. Only after resolving the issues I proceed with unblocking firewall traffic.

Nextcloud's self check makes a request to the URL configured in overwrite.cli.url (config.php) and looks for an HSTS header in the response. In my case this request ran into a timeout. Nextcloud displayed me then the error message that I found here:

server/apps/settings/lib/SetupChecks/SecurityHeaders.php

Line 109 in 56b9974

$msg .= $this->l10n->t('- The `Strict-Transport-Security` HTTP header is malformed: `%s`. For enhanced security, it is recommended to enable HSTS.', [$transportSecurityValidity]) . "\n";

HSTS is correctly set up on my reverse proxy. But as the Nextcloud instance could not reach the proxy it showed me this warning. I expect Nextcloud to display me an error message like "Some tests could not be performed due to a network timeout to the configured public address <address> configured in the config.php"

[joshtrichards]

Unless something really weird is going on, it only gets that far if both (a) a connection to one of the test URLs succeeds and; (b) there is header to check.

You can simulate a that check by running curl from your Nextcloud Server when you have things blocked:

curl -IL https://domain.tld/index.php/heartbeat

Keep in mind that other URLs are also checked, not just overwrite.cli.url (though it's preferred), including all of your listed trusted_domains. If even one responds, it might trigger this I guess.

[Somebodyisnobody]

Keep in mind that other URLs are also checked, not just overwrite.cli.url (though it's preferred), including all of your listed trusted_domains. If even one responds, it might trigger this I guess.

You could be right: The public ip of the Nextcloud instance itself is also added to the trusted domains (but behind there is only the apache listening on port 80, not TLS 443). So curl -IL http://<nextcloud-machine-ip>:80 was successful.

(b) there is header to check.

But of course on HTTP you will never get a HSTS header back ;) I think this is an edge case in the logic.

What about separating Secure-Headers in two parts:

• Headers hat can be available in unsecured requests
• Headers hat can be available in secured requests

The checks are then mapped to at least one group. If a header requiring a secured request is to be checked but there could no secured connection established the error message could be (specific example):

We could not check wether the Strict-Transport Header is set correctly. A secured connection could not be established.
Established connections: http://<nextcloud-machine-ip>:80
Failed connections: https://nextcloud.mydomain.com:443, http://nextcloud.mydomain.com:80, https://<nextcloud-machine-ip>:443

(<nextcloud-machine-ip> in trusted_domains, nextcloud.mydomain.com in overwrite.cli.url)