Fixed.
Policy set on plaintext port
HSTS policies must not be transmitted over insecure channels.
Location: http://whonix.org/
This was a non-issue for security. Only a warning. But to add kicksecure.com to hstspreload.org it needed to be fixed anyhow.
Status: kicksecure.com is currently preloaded, but has the following issues:
(And the whonix.org and kicksecure.com server share the same private server configuration package with string/replace whonix.org/kicksecure.com where needed.)
https://hstspreload.org/?domain=kicksecure.com
is now also fixed.
Make the TLS/SSL read at 100% when tested by ssllabs, to do that check:
These are old posts. What ssllabs considers 100% has changed since. Configs from back then donāt work anymore nowadays.
Note: there are very, very few websites that have a all 100% green rating on ssllabs. Just found 1 so far:
https://www.ssllabs.com/ssltest/analyze.html?d=dustri.org&s=212.51.141.142
Testing kicksecure.com nginx config:
ssl_ciphers !ECDHE-ECDSA-AES128-GCM-SHA256:!ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:!DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384;
ssl_prefer_server_ciphers on;
Visiting with Firefox, clicked on the lock symbol in the URL bar, shows:
TLS_AES_256_GCM_SHA384, 256 bit keys, TLS 1.3
Already prefect?
https://www.ssllabs.com/ssltest/analyze.html?d=kicksecure.com shows A+ (already highest rating) (I have never seen A++ or A+++) but āonlyā 90% for Key Exchange and Cipher Strength.
TLS 1.3 (suites in server-preferred order)
TLS_AES_256_GCM_SHA384 (0x1302) ECDH x25519 (eq. 3072 bits RSA) FS 256
TLS_CHACHA20_POLY1305_SHA256 (0x1303) ECDH x25519 (eq. 3072 bits RSA) FS 256
TLS_AES_128_GCM_SHA256 (0x1301) ECDH x25519 (eq. 3072 bits RSA) FS 128
TLS_AES_128_GCM_SHA256 offends ssllabs and prevents 100%. Disabling that cipher would break the TLSv1.3 standard as per auote RFC 8446 - The Transport Layer Security (TLS) Protocol Version 1.3
A TLS-compliant application MUST implement the TLS_AES_128_GCM_SHA256 [GCM] cipher suite and SHOULD implement the TLS_AES_256_GCM_SHA384 [GCM] and TLS_CHACHA20_POLY1305_SHA256 [RFC8439] cipher suites (see Appendix B.4).
More reading on the topic:
Quote avoid too much security by ssllabs
Avoid Too Much Security
The cryptographic handshake, which is used to establish secure connections, is an operation for which the cost is highly influenced by private key size. Using a key that is too short is insecure, but using a key that is too long will result in ātoo muchā security and slow operation. For most web sites, using RSA keys stronger than 2,048 bits and ECDSA keys stronger than 256 bits is a waste of CPU power and might impair user experience. Similarly, there is little benefit to increasing the strength of the ephemeral key exchange beyond 2,048 bits for DHE and 256 bits for ECDHE. There are no clear benefits of using encryption above 128 bits.
It screws some old clients, and p384 is much slower than p256 (on my VPS itās even twice slower than rsa2048), so itās better not to use this in production, unless you are extremely paranoid about the possibility of cracking AES-128 and/or EC P-256.
https://blog.germancoding.com/2020/09/18/why-100-isnt-always-the-best-score/
Test on TLS Logjam Test - Verify CVE-2015-4000 Vulnerability | KeyCDN Tools also looks good.
Not vulnerable to TLS Logjam attacks.
DHE is supported. Server Temp Key: DH, 4096 bits (>= 2048 bits is recommended).
ECDHE is supported.
After reading lots on the topic, I cannot find any authoritative/expert recommendations that recommend/urge to make sure that ssllabs shows 100% Key Exchange and 100% Cipher Strength instead of āonly 90%ā on top of an existing A+ rating. On the contrary, most are discouraging it.
The security gain is disputed, cannot be quantified, worsens compatibility, isnāt common security practice. Even websites that deal with millions or even billions of USD value such as banks and crypto exchanges donāt go for this. Neither any security-focused operating systems.
Since Whonix isnāt a web application project, bank or crypto exchange Iāve decided not to attempt to be special here.
In the wider context
it doesnāt seem any threat model would be addressed here.
Further research, discussion, implementation could take many more hours and these donāt seem appropriately allocated in context of other tasks.
Additional, Daniel from danwin1210 said:
Hello,
thanks for the suggestion, but improving the Key Exchange is not possible, as it is not yet supported by Let's Encrypt to issue ECC certificates with more than 384 bits and 521 is also not supported by most browsers anyway. The only way to archive this is by using RSA keys instead of ECC, which is much slower, requires more bandwidth and will eventually get deprecated, as more and more people are migrating to modern ECC keys.
Cipher strength can be limited, but this will break compatibility with some clients. Modern clients will try to use the most secure ciphers first, but there are still some that will break by removing 128 bit ciphers.
Regards,
Daniel
No support for ECC P-521, only ECC P-384:
danwin1210 website changed from RSA to ECC P-384:
So the chain will be:
End-entity certificate ā E1 ā ISRG Root X2 ā ISRG Root X1
Which is better than ours which has expired cert with RSA:
According to:
If the signing key is P-384, the signature MUST use ECDSA with SHA-384. When encoded, the AlgorithmIdentifier MUST be byte-for-byte identical with the following hex-encoded bytes: 300a06082a8648ce3d040303.
This is i think useful guide by certbot:
https://eff-certbot.readthedocs.io/en/stable/using.html#using-ecdsa-keys
According to:
This means I need to take the default CipherSuites and simply remove any that use a cipher smaller than 256bit.
We need to remove ciphers which are 128 and keep 256 or above: (for 1.3 and 1.2)
By this we will have 100% best ciphers, But only best available Key Exchange not 100%.
We can have 100% key exchange but only available now with RSA 4096 (according to daneil its slower) but not with ECC P-521 due to the limitation mentioned above.
More about ssllabs ratings can be found here:
This is a non-issue according to letsencrypt. Quote:
What should you do? For most people, nothing at all!
Test websites also not showing a warning or downgrade the rating.
Moving to a EC 384 bits (SHA384withECDSA) certificate might make sense but thereās no rush.
Awesome.
In theory, yes. I tested the authorās website blog.bracebin.com with ssllabs and it didnāt have 4x 100%. Therefore it might be outdated and not work anymore. Also instructions arenāt for nginx so I cannot apply them.
I was also reading:
In one reply, the author included a link to a blog post:
And then tested the authorās website dawnbringer.net on ssllabs but it has only 2x 100% and 2x 90%.
My website uses Cloudflare as a proxy and waf but scores lower than that. But all my internal hosts use this profile since I only want to use TLS1.2 or newer to begin with. This domain (oceandns) does have the above profile running: Check SSL Labs here. For an ECC/ECDSA enabled site check: here
The test result is āonlyā 4x 100% but with an A rather than an A+ rating. So still not the perfection youāre seeking here.
For an ECC/ECDSA enabled site check: here
Actually outdated. Not ECC/ECDSA. Actually: RSA 4096 bits (SHA256withRSA)
Also affected by the letsencrypt expired root āissueā.
So in summary, I havenāt seen any server on ssllabs.com, that has:
A+ (not āonlyā A),that has published its server config so others can reproduce this.
Reply from my preivous post DNS Certification Authority Authorization (CAA) Policy / DNSSEC for whonix.org / ssllabs.com test results / OCSP ERROR: Exception: connect timed out [http://r3.o.lencr.org] / Must-Staple - #27 by Patrick applies.
to use the E1 key, there is an allowlist, which you have to sign up for
This is done.
This is done.
To make it happen:
Disabling 128 bits ciphers on TLS1.3 on nginx
This directive appeared in version 1.19.4.
The server is currently on the same nginx version as Debian bullseye.
1.18.0
Therefore this option isnāt available yet.
In debian next release bookworm this option going to be there.
This has been implemented.
related:
ssllabs bug:
Your certificateās public key is only 2048-bit RSA. The key exchange score comes from the strength of the ephemeral key exchange and the strength of the public key. You need a 4096-bit RSA (or 384-bit ECC) key on your certificate to get 100%.