Redirection from HTTP to HTTPS not to the same host:
When HSTS is used, the plaintext port should redirect to the HTTPS variant of the same hostname. This approach ensures that HSTS is enabled on that hostname, even if later the client is sent elsewhere. A redirection to another host is only safe if it is for a parent host that has HSTS with includeSubDomains enabled, but that’s not the case here.
I am inclined to ignore this unless someone has an argument why it is an actual issue.
Reason: no actual security issue for anyone.
In case of:
in case of no MITM: browser will ignore the HSTS header
in case of MITM: the MITM can inject whatever malicious HSTS header
since this is over an unencrypted/unauthenticated http connection (this is about the http version (non-TLS) (stub to redirect to https / TLS)).
Also…
In case browser honors HSTS preload list: this wouldn’t happen anyhow
In case browser ignores HSTS preload list: then whatever the clearnet version headers are cannot help anyhow
It might be counter to some standard but I don’t see how it helps. It would complicate server nginx config for minimal gain (namely making a test website happy).
This seems a bit pointless to me to redirect http://whonix.org (which we don’t use - whonix.org currently doesn’t use the non-subdomain, main domian) except for redirect to https://whonix.org to only then redirect to https://www.whonix.org. That would be a double redirect and make the website slower for those who just type whonix.org. Other test websites focused on website performance would complain about the double redirect.
Similar as above.
In case browser honors HSTS preload list: then we don’t have a problem - first visit will use https (TLS) version even if user typed http (cleartext) version whonix.org
In case browser ignores HSTS preload list: then nothing helps anyhow.
This policy appears to already be preloaded (or pending), but it doesn’t satisfies preloading requirements. Because this is an older preload entry there is currently no danger of being removed from the list, but that might change in the future. We recommend that you update your policy to match what is preloaded.
Previously when we required manually by e-mail or mailing list (forgot) years ago to be included on HSTS preload list there was no such keyword. Nowadays there is. Will add soon to be future proof.
This one I don’t know and can only be fixed on gandi site. Dunno they’ll agree this is an issue. Could you contact them please?
You’re getting this warning because the nameservers are all in the same block and if that single route goes offline for some reason, all your nameservers go down. It’s generally best to spread these out geographically to minimize your exposure to localized events.
They’re just looking out for you here. Typically you should have 3-4 different nameservers on different backbone providers in different regions so that no single failure, even at the provider level, can take them all down.
SOA MNAME entry - WARNING: SOA MNAME (mydomain.com) is not listed as a primary nameserver at your parent nameserver!
This one you can actually fixquite easily. The SOA record looks like this:
;; ANSWER SECTION:
google.com. 86400 IN SOA ns1.google.com. dns-admin.google.com. 1399740 7200 1800 1209600 300
You have the domain name, TTL, protocol, record type. Then “mname” which should be the name of the PRIMARY domain name server, followed by “rname” which is the zone admin email (using a . instead of an @) and then serial #, refresh, retry, expire, and a default Time-To-Live for records.
Your domains mname should be the primary name server.
When HSTS is used, the plaintext port should redirect to the HTTPS variant of the same hostname. This approach ensures that HSTS is enabled on that hostname, even if later the client is sent elsewhere. A redirection to another host is only safe if it is for a parent host that has HSTS with includeSubDomains enabled, but that’s not the case here.
Starting point: http://example.com
(Domain name redacted. Not really using example.com.)
hardenize is suggesting a redirection chain http://example.com → https://example.com → https://www.example.com/. What hardenize calls good, other tests complain about as a double redirect.
How would that be better than a simple redirection http://example.com → https://www.example.com/?
So is this double redirect that hardenize suggests really a security net gain? Or in other words, does the double redirect really solve a security issue?
When a browser is visiting example.com apex domain (non-TLS). The server replies in its HTTP location header:
A) location: http://www.example.com, or
B) location: https://www.example.com
Why would A) be more secure?
Man-in-the-middle (MITM) attack vs none:
C) in case of no MITM: browser will ignore the HSTS header
D) in case of MITM: the MITM can inject whatever malicious HSTS header
HSTS preload vs HSTS not preloaded:
E) In case browser honors HSTS preload list: this wouldn’t happen anyhow. Browser would access TLS version in any case.
F) In case browser ignores HSTS preload list: then whatever the clearnet version headers are, these cannot help anyhow.
Why not drop-www instead? drop-www vs yes-www is a completely different argument and shouldn’t be mixed in here.
Status: kicksecure.com is currently preloaded, but no longer meets the requirements. It may be at risk of removal.
Error: HTTP redirects to www first http://kicksecure.com (HTTP) should immediately redirect to https://kicksecure.com (HTTPS) before adding the www subdomain. Right now, the first redirect is to https://www.kicksecure.com/. The extra redirect is required to ensure that any browser which supports HSTS will record the HSTS entry for the top level domain, not just the subdomain.
Double redirect has been implemented. Shouldn’t be too bad. All search engine results and most other links include the www subdomain. For those writing manually whonix.org into the browser and not having HSTS, will on first visit experience the double redirect. But that should rarely be the case as whonix.org is already in all HSTS lists of all major browsers.