DNS Certification Authority Authorization (CAA) Policy as well as
DNSSEC has been set up for whonix.org by @mig5.
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
We also have the Expect-CT header, and more importantly, we are now running certspotter to monitor the public Certificate Transparency Logs for any unexpected issuing of whonix.org SSL certificates that were not made by us.
Our website got B as our SSL seems to support alot of weak Diffie-Hellman key exchange parameters
B for: 18.104.22.168
A+ for: 2001:41d0:2:7d51:0:0:0:0
but it has problems as well such as:
Thanks for bringing this to my attention. Fortunately it only affected the whonix.org ‘stub’ entry point, which these days doesn’t serve anything except a redirect to www.whonix.org (where all ‘real’ traffic goes), and which was not affected (still A+).
Not concerned much about the reported weak ciphers, browser would have to be targeted with a MITM + downgrade attack which is probably mitigated in other ways, and not all browsers may be able to handle the stronger ciphers (but most modern browsers will favour the stronger ones anyway)
TLS 1.1 and CBC cipher considered weak now better to be deprecated for security reasons:
Also now TLS 1.3 available with Lets Encrypt, is it good idea to support it ?
This is now implemented, Only thing left is removing weak ciphers:
0xc027) ECDH secp384r1 (eq. 7680 bits RSA) FS WEAK
128 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (
0xc013) ECDH secp384r1 (eq. 7680 bits RSA) FS WEAK
128 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (
0xc028) ECDH secp384r1 (eq. 7680 bits RSA) FS WEAK
256 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (
0xc014) ECDH secp384r1 (eq. 7680 bits RSA) FS WEAK
256 TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 (
0x67) DH 4096 bits FS WEAK
128 TLS_DHE_RSA_WITH_AES_128_CBC_SHA (
0x33) DH 4096 bits FS WEAK
128 TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 (
0x6b) DH 4096 bits FS WEAK
256 TLS_DHE_RSA_WITH_AES_256_CBC_SHA (
0x39) DH 4096 bits FS WEAK
256 TLS_RSA_WITH_AES_128_GCM_SHA256 (
128 TLS_RSA_WITH_AES_256_GCM_SHA384 (
256 TLS_RSA_WITH_AES_128_CBC_SHA256 (
128 TLS_RSA_WITH_AES_256_CBC_SHA256 (
256 TLS_RSA_WITH_AES_128_CBC_SHA (
128 TLS_RSA_WITH_AES_256_CBC_SHA (
256 — — TLS_RSA_WITH_AES_256_CCM (
256 TLS_RSA_WITH_AES_128_CCM_8 (
128 TLS_RSA_WITH_AES_128_CCM (
128 TLS_ECDHE_RSA_WITH_CAMELLIA_256_CBC_SHA384 (
0xc077) ECDH secp384r1 (eq. 7680 bits RSA) FS WEAK
256 TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA256 (
0xc4) DH 4096 bits FS WEAK
256 TLS_ECDHE_RSA_WITH_CAMELLIA_128_CBC_SHA256 (
0xc076) ECDH secp384r1 (eq. 7680 bits RSA) FS WEAK
128 TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA256 (
0xbe) DH 4096 bits FS WEAK
128 TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA (
0x88) DH 4096 bits FS WEAK
256 TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA (
0x45) DH 4096 bits FS WEAK
128 TLS_RSA_WITH_CAMELLIA_256_CBC_SHA256 (
256 TLS_RSA_WITH_CAMELLIA_128_CBC_SHA256 (
128 TLS_RSA_WITH_CAMELLIA_256_CBC_SHA (
256 TLS_RSA_WITH_CAMELLIA_128_CBC_SHA (
Intermediate configuration from https://ssl-config.mozilla.org now:
Supports Firefox 27, Android 4.4.2, Chrome 31, Edge, IE 11 on Windows 7, Java 8u31, OpenSSL 1.0.1, Opera 20, and Safari 9
General-purpose servers with a variety of clients, recommended for almost all systems
Another option would be
Supports Firefox 63, Android 10.0, Chrome 70, Edge 75, Java 11, OpenSSL 1.1.1, Opera 57, and Safari 12.1
Services with clients that support TLS 1.3 and don’t need backward compatibility
But probably no good idea. Not even
ssllabs.com using that. Neither
Why not? I dont believe anyone until now using these outdated versions of browsers. Let alone he will visit whonix with them.
Because no related peers are doing that, no known security issues, Website Tests, Comparison with Others, Introduction, Whonix is a software project, not a web service, I don’t wish to run an experiment.
Revocation status Validation error OCSP ERROR: Exception: connect timed out [http://r3.o.lencr.org]
- Enable Must-Staple
OCSP Must-Staple requires OCSP Stapling for the certificate. If a browser comes into contact with a certificate without OCSP Stapling, it will be rejected. Not only does Must-Staple mitigate the threat of downgrade attacks, it also reduces unnecessary traffic to the CA’s OCSP responders, improving responsiveness and overall OCSP performance.
OCSP Must-Staple makes use of the recently specified TLS Feature Extension. When a CA adds this extension to a certificate, it requires your browser to ensure a stapled OCSP response is present in the TLS handshake. If an OCSP response is not present, the connection will fail and Firefox will display a non-overridable error page.
I don’t think the error is on
whonix.org timed out.
Was looking for an alternative online test website. Didn’t find any but here’s a test that can be performed manually by anyone. As per: https://www.digicert.com/kb/ssl-support/nginx-enable-ocsp-stapling-on-server.htm
openssl s_client -connect whonix.org:443 -status
CONNECTED(00000003) OCSP response: ====================================== OCSP Response Data: OCSP Response Status: successful (0x0) Response Type: Basic OCSP Response Version: 1 (0x0) Responder Id: C = US, O = Let's Encrypt, CN = R3 Produced At: May 5 09:56:00 2021 GMT Responses: Certificate ID: Hash Algorithm: sha1 Issuer Name Hash: 48DAC9A0FB2BD32D4FF0DE68D2F567B735F9B3C4 Issuer Key Hash: 142EB317B75856CBAE500940E61FAF9D8B14C2C6 Serial Number: 047A4A332A89C7214694373185485014C2F2 Cert Status: good This Update: May 5 09:00:00 2021 GMT Next Update: May 12 09:00:00 2021 GMT Signature Algorithm: sha256WithRSAEncryption a7:f8:dc:de:5b:3c:7c:48:03:67:8b:55:88:65:c9:7c:1d:ce: 42:03:11:3f:47:df:de:15:82:22:d5:cd:1c:f8:e5:46:20:39: a4:31:2c:d0:42:dd:84:40:6d:c1:f3:bc:c8:08:04:0d:25:fc: a7:0d:a2:86:74:7e:e0:c6:b4:b5:f6:94:ba:fe:24:e0:7d:57: c0:d4:e2:e6:4b:b1:91:fc:54:5a:5c:7e:9d:46:9c:48:fd:c8: 51:b6:c5:18:25:fc:d5:77:4a:da:bc:d5:cc:45:1d:74:40:bd: 6a:df:16:ba:af:35:27:ff:36:ff:5b:07:8e:62:c7:4e:0d:ad: 31:bd:12:8a:c7:89:4d:a8:95:d3:18:80:56:f9:12:72:fb:cc: 41:c1:a2:24:4b:d3:c1:d0:71:de:43:b0:c9:ad:1e:31:14:d4: af:f1:b9:57:55:0a:4c:9f:d5:87:f4:b8:90:bc:ba:8a:28:3e: cd:63:95:22:2d:8c:76:ae:56:1c:78:e0:9a:01:5c:f6:a1:3b: b0:4e:2e:d3:4d:04:f5:fd:e4:c5:5e:78:ab:06:c8:eb:b6:ef: 89:53:f4:3f:77:8a:3d:8b:07:3b:bc:ed:1e:31:62:db:ee:a7: 8b:f7:57:3e:cd:6f:be:e8:f2:70:a5:70:a5:02:3b:e4:1c:6b: 89:9b:a2:8e ======================================
Same error for
Same error for
Discussed Let’s Encrypt:
Most likely nothing wrong on
Yes, if you scan whonix again now doesnt show the error.
Didnt expect ssllabs would give false positive… my bad.
I missed that. Looked into that now.
whonix.org's CA is doing that.
OCSP Must Staple No
nginx support is lacking
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:
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)
@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.
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:
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
Weak or insecure signature, but no impact on root certificate
site:letsencrypt.org short chain
site:letsencrypt.org long chain
site:letsencrypt.org Weak or insecure signature, but no impact on root certificate
- No security impact. It’s a non-issue issue besides the annoying warning.
- Silencing the warning would result in loosing some device support. These devices would TLS errors which would probably cause more alarm than this.
Will document on and refer to Website and Server Tests instead.
Fixed kicksecure.com OSCP stapling.