no clean HSTS-Preload / DNSSEC

Checking TLS configs:

It says:

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.

Starting point: http://whonix.org

Current redirection: https://www.whonix.org/

Expected redirection: https://whonix.org



Policy set on plaintext port

HSTS policies must not be transmitted over insecure channels.

Location: http://whonix.org/

Policy set on plaintext port

HSTS policies must not be transmitted over insecure channels.

Location: http://www.whonix.org/

DNSSEC warnings (not in our hands to fix mostly but shall we contact?):

https://zonemaster.net/result/e0d85cd688164b60 :

ADDRESS WARNING Nameserver ns-61-b.gandi.net has an IP address ( without PTR configured.

14 CONNECTIVITY WARNING All nameservers in the delegation have IPv4 addresses in the same AS (209453).
15 CONNECTIVITY WARNING All nameservers in the delegation have IPv6 addresses in the same AS (209453).
16 CONNECTIVITY WARNING All nameservers in the delegation are in the same AS (209453).

0 ZONE NOTICE SOA ‘mname’ nameserver (ns1.gandi.net) is not listed in “parent” NS records for tested zone (ns-10-c.gandi.net; ns-185-a.gandi.net; ns-61-b.gandi.net).
1 ZONE NOTICE SOA ‘refresh’ value (10800) is less than the recommended minimum (14400).

No idea how important is that, cc @Patrick @HulaHoop


Thank you for reporting this!

Archived link to document progress, if any.


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/unauthetnicated https connection (this is about the http version (non-TLS) (stub to redirect to https / TLS)).


  • 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.

I will apply advice from
which contains the preload keyword.

Strict-Transport-Security: max-age=63072000; includeSubDomains; preload

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?

Please scrutinize this. @HulaHoop

1 Like

Done. Looks better now.


HSTS policies must not be transmitted over insecure channels.

Found this:

I agree. Better set one time too much than one time too few.

https://hstspreload.org also looked good (before and now):


curl --head http://whonix.org

Also looks already for cleartext version (redirection to TLS stub).

Strict-Transport-Security: max-age=0
Expect-CT: max-age=0

Is the same as for Whonix onion domain. (Must not set HSTS there.)

ssllabs test HSTS preloading also passed:


Strict Transport Security (HSTS) Yes
max-age=63072000; includeSubdomains; preload
HSTS Preloading Chrome Edge Firefox IE

1 Like

What this means and how to fix it if necessary:

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:

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.

Benign. Can be ignored

[Imprint] [Privacy Policy] [Cookie Policy] [Terms of Use] [E-Sign Consent] [DMCA] [Investors] [Priority Support] [Professional Support]