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

Website
,
41
1 Like
42

Dev/About Infrastructure - Kicksecure chapter OSCP in Kicksecure wiki

1 Like
43

Err:1 tor+https://deb.whonix.org bookworm-developers InRelease
Certificate verification failed: The certificate is NOT trusted. The revocation or OCSP data are old and have been superseded. Could not handshake: Error in the certificate verification. [IP: 127.0.0.1 8082]
Reading package lists… Done
E: Failed to fetch tor+https://deb.whonix.org/dists/bookworm-developers/InRelease Certificate verification failed: The certificate is NOT trusted. The revocation or OCSP data are old and have been superseded. Could not handshake: Error in the certificate verification. [IP: 127.0.0.1 8082]
E: Some index files failed to download. They have been ignored, or old ones used instead.

nginx ssl_stapling_file:

Now hopefully fixed.

2 Likes
44

SSL_ERROR_RX_RECORD_TOO_LONG

1 Like
45

Side note:

DHE suites not supported: This server doesn’t support the Diffie-Hellman (DH) key exchange.

Since our certificate is based on ECDSA (Not RSA), we dont need DHE for PFS.

Although this owasp cheat sheet says to use DHE but it doesnt point out if you are using ECDSA vs RSA. Thus using ffdhe8192 (or lower variants) is only for backward compatibility were devices doesn’t support elliptic curve and rely on DHE (which is something against the principle of keep it safe and updated) for connection.

1 Like
46

cc @Patrick

2 Likes
47

OCSP deprecated upstream:

Therefore disabled:

2 Likes
48

Daniel Winzen (danwin) made a test on using X448 only for the server:

Result: It didnt work/connect, It shows Error code:SSL_ERROR_NO_CYPHER_OVERLAP = LulzSec

(investigation needed to know where is the issue)

But we know for sure that

sect571r1, sect571k1, secp521r1, brainpoolP512r1, sect409r1, sect409k1

Do actually work.

This is not about post-quantum resistant or not, just best security practice.

For post quantum specifically:

There isnt real pure PQC used/supported yet by browsers, only hybrid one which is X25519+ML-KEM-768, This is not available in debian 12 nor in 13 due to lack the of OQS Provider package (unless git clone used of course…).

What can be done in my opinion:

  • Keep x448, x25519
  • Add sect571r1, sect571k1
  • Remove the rest

By having this done we dont lose any preferred key while keeping best secure ones.

1 Like
49

Any functional and recommended nginx ssl_ecdh_curve (or other) setting?

1 Like
50

After further dig up and testing, x448 and x25591 are enough (doesnt matter which comes first):

ssl_ecdh_curve x448:x25519;

Note: Both browsers FF and Chromium based doesnt load x448 if used alone.

What left after this we wait until pure PQC becomes reality and supported by browsers and SSL libraries.

51

With this configuration, ssllabs will bug out.

HTTP request to this server failed, see below for details.

Strict Transport Security (HSTS) Unknown (failed HTTP request?)

No other changes. Reverted. ssllabs no longer bugging out.

Already been there a while ago…

52

Yeah they are using old, not updated checker, compare that to another checkers like hardenizer or so, you wont find something wrong.

Unrelated to make the keys 100%, because even this checker is based on RSA calculations not ECC (there is no 4096 key size you can get from ECC).

53

No issues on hardenize indeed with that setting.

What do you mean by 100%? On ssllabs?

Doesn’t seem very useful to me to chase 100% on unmaintained test website ssllabs.

The penalty being:

Strict Transport Security (HSTS) Unknown (failed HTTP request?)

This has more potential for FUD than the 90 vs 100% which is the norm.

SSL Server Test: goldhammer.se (Powered by Qualys SSL Labs) has “all 100%”, no HSTS error but

sect571r1, sect571k1, secp521r1, brainpoolP512r1, sect409r1, sect409k1, brainpoolP384r1, secp384r1 (server preferred order)

So forgetting about any unmaintained test websites…

What actual authoritative recommendations exist?

https://ssl-config.mozilla.org with choice “modern” (“best”) suggest:

ssl_ecdh_curve X25519:prime256v1:secp384r1;

Good?

In nixos/nginx: add ssl_ecdh_curve to recommendedTlsSettings, remove ssl_stapling by teutat3s ¡ Pull Request #428594 ¡ NixOS/nixpkgs ¡ GitHub it is currently being suggested the same as above:

ssl_ecdh_curve X25519:prime256v1:secp384r1;

Maybe dicuss im above ticket for wider input on best settings.

1 Like
54

Yes in ssllabs, old software

Yeah forget about ssllabs, just broken.

Hes using old keys, everything in that website is RSA based. This can be considered the best before 15 years ago, not now.

Yep good, adding x448 wont harm as well.

1 Like
55

Using that now.

1 Like
56
1 Like