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


is now also fixed.

Make the TLS/SSL read at 100% when tested by ssllabs, to do that check:

1 Like

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:

Testing kicksecure.com nginx config:

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.


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.

1 Like
1 Like
1 Like

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.

1 Like

Additional, Daniel from danwin1210 said:


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.

1 Like

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:


1 Like

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:

1 Like

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.


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:

  • ECC,
  • A+ (not “only” A),
  • 4x 100%,
  • no letsencrypt expired root “issue”,
  • no other warnings on ssllabs,
  • is nginx based,

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.

1 Like

to use the E1 key, there is an allowlist, which you have to sign up for

Chain of Trust - Let's Encrypt

This is done.

This is done.

1 Like

To make it happen:

1 Like

Disabling 128 bits ciphers on TLS1.3 on nginx

Module ngx_http_ssl_module

This directive appeared in version 1.19.4.

The server is currently on the same nginx version as Debian bullseye.

Debian -- Details of package nginx in bullseye


Therefore this option isn’t available yet.

1 Like

In debian next release bookworm this option going to be there.

1 Like
1 Like

This has been implemented.


1 Like

ssllabs bug:

1 Like

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

1 Like