DNS Certification Authority Authorization (CAA) Policy
as well as DNSSEC
has been set up for whonix.org by @mig5.
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: 94.23.250.81
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+).
Fixed for the whonix.org stub which was lacking a couple of ssl parameters in its vhost that the www.whonix.org vhost had.
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:
https://www.ssllabs.com/ssltest/analyze.html?d=deb.whonix.org&s=95.216.25.250&latest
Also now TLS 1.3 available with Lets Encrypt, is it good idea to support it ?
cc @Patrick
This is now implemented, Only thing left is removing weak ciphers:
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 ( 0xc027
) ECDH secp384r1 (eq. 7680 bits RSA) FS WEAK128 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA ( 0xc013
) ECDH secp384r1 (eq. 7680 bits RSA) FS WEAK128 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 ( 0xc028
) ECDH secp384r1 (eq. 7680 bits RSA) FS WEAK256 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA ( 0xc014
) ECDH secp384r1 (eq. 7680 bits RSA) FS WEAK256 TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 ( 0x67
) DH 4096 bits FS WEAK128 TLS_DHE_RSA_WITH_AES_128_CBC_SHA ( 0x33
) DH 4096 bits FS WEAK128 TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 ( 0x6b
) DH 4096 bits FS WEAK256 TLS_DHE_RSA_WITH_AES_256_CBC_SHA ( 0x39
) DH 4096 bits FS WEAK256 TLS_RSA_WITH_AES_128_GCM_SHA256 ( 0x9c
) WEAK128 TLS_RSA_WITH_AES_256_GCM_SHA384 ( 0x9d
) WEAK256 TLS_RSA_WITH_AES_128_CBC_SHA256 ( 0x3c
) WEAK128 TLS_RSA_WITH_AES_256_CBC_SHA256 ( 0x3d
) WEAK256 TLS_RSA_WITH_AES_128_CBC_SHA ( 0x2f
) WEAK128 TLS_RSA_WITH_AES_256_CBC_SHA ( 0x35
) WEAKTLS_RSA_WITH_AES_256_CCM_8 ( 0xc0a1
) WEAK256 — — TLS_RSA_WITH_AES_256_CCM ( 0xc09d
) WEAK256 TLS_RSA_WITH_AES_128_CCM_8 ( 0xc0a0
) WEAK128 TLS_RSA_WITH_AES_128_CCM ( 0xc09c
) WEAK128 TLS_ECDHE_RSA_WITH_CAMELLIA_256_CBC_SHA384 ( 0xc077
) ECDH secp384r1 (eq. 7680 bits RSA) FS WEAK256 TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA256 ( 0xc4
) DH 4096 bits FS WEAK256 TLS_ECDHE_RSA_WITH_CAMELLIA_128_CBC_SHA256 ( 0xc076
) ECDH secp384r1 (eq. 7680 bits RSA) FS WEAK128 TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA256 ( 0xbe
) DH 4096 bits FS WEAK128 TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA ( 0x88
) DH 4096 bits FS WEAK256 TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA ( 0x45
) DH 4096 bits FS WEAK128 TLS_RSA_WITH_CAMELLIA_256_CBC_SHA256 ( 0xc0
) WEAK256 TLS_RSA_WITH_CAMELLIA_128_CBC_SHA256 ( 0xba
) WEAK128 TLS_RSA_WITH_CAMELLIA_256_CBC_SHA ( 0x84
) WEAK256 TLS_RSA_WITH_CAMELLIA_128_CBC_SHA ( 0x41
) WEAK
Using 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 Modern
:
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 mozilla.com
, ssllabs.com
using that. Neither torproject.org
.
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.
https://www.ssllabs.com/ssltest/analyze.html?d=whonix.org&s=95.216.25.250&latest
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
side.
Clearly not 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
======================================
Seems functional.
Same error for certbot.eff.org
.
https://web.archive.org/web/20210507054847/https://www.ssllabs.com/ssltest/analyze.html?d=certbot.eff.org&hideResults=on
Same error for letsencrypt.org
.
Discussed Let’s Encrypt:
Most likely nothing wrong on whonix.org
.
Yes, if you scan whonix again now doesnt show the error.
Didnt expect ssllabs would give false positive… my bad.
Not good?
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
- 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.