I missed that. Looked into that now.
Not even whonix.org’s CA is doing that.
OCSP Must Staple No
nginx support is lacking
https://trac.nginx.org/nginx/ticket/812
Quote mnordhoff Community Moderator;
“No, the web is not ready.”
So, no. For now, not a good idea. Possibly in future. Thanks for bringing that up!
Checking grapheneos website they are using nginx + must staple:
https://www.ssllabs.com/ssltest/analyze.html?d=grapheneos.org&s=192.99.43.50
can you recheck again?
There is a workaround GrapheneOS using it:
for TLS session keys
also you’ll need to provision a certificate with the must staple parameter (if not already)
grapheneos nginx:
@patrick Gabe from grapheneos said:
you could also save people battery on phones without AES
ssl_conf_command Options PrioritizeChaCha;
this means that on devices without AES support, chacha20 is preferred over AES
its faster and should use less battery
helpful for people who dont have good hardware
he actually gave alot of advises this is one of them, thanks to him and to @madaidan who told me where to go.
Interesting.
If it’s not in nginx it seems too hacky and not worth potential trouble since there is no clear threat model.
For general context:
https://www.ssllabs.com/ssltest/analyze.html?d=whonix.org&s=95.216.25.250&latest
In trust store DST Root CA X3 Self-signed
Fingerprint SHA256: 0687260331a72403d909f105e69bcf0d32e1bd2493ffc6d9206d11bcd6770739
Pin SHA256: Vjs8r4z+80wjNcr1YKepWQboSIRi63WsWXhIMN+eWys=
RSA 2048 bits (e 65537) / SHA1withRSA
Valid until: Thu, 30 Sep 2021 14:01:15 UTC
EXPIRED
Weak or insecure signature, but no impact on root certificate
See:
search terms:
site:letsencrypt.org short chain
site:letsencrypt.org long chain
site:letsencrypt.org Weak or insecure signature, but no impact on root certificate
Will document on and refer to Website and Server Tests instead.
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.