{{Title|title= Website and Server Tests }} {{Header}} {{#seo: |description=Testing the {{project_name_long}} server with test websites such as hardenize.com / securityheaders.com / Mozilla Observatory / SSL Labs / hstspreload.org. |image=Websitetest.jpg }} [[File:Websitetest.jpg|thumb]] {{intro| Testing the {{project_name_short}} server with test websites such as hardenize.com / securityheaders.com / Mozilla Observatory / SSL Labs / hstspreload.org. }} = Introduction = Security is not a checklist, nor is it simply about having website tests show a lot of green or positive results for features like:
* SSL certificate * HTTP Strict Transport Security (HSTS) * Certification Authority Authorization (CAA) Policy * Expect-CT header * Domain Name System Security Extensions (DNSSEC) * Content Security Policy (CSP) * Feature-Policy * Mail Transfer Agent Strict Transport Security (MTA-STS) * SMTP TLS Reporting (TLS-RPT) * DNS-based Authentication of Named Entities (DANE) * Sender Policy Framework (SPF) * DomainKeys Identified Mail (DKIM) * Domain-based Message Authentication, Reporting and Conformance (DMARC) * Frame Options * Cross-Site Scripting (XSS) Protection * Content Type Options
While it is nice to have these website or server security features, in a similar fashion to [[Browser Tests]] the context is important and there are many false positives. [https://phabricator.wikimedia.org/T165455#3826451 Quote] * https://phabricator.wikimedia.org/p/Bawolff/ * https://wikitech.wikimedia.org/wiki/User:Brian_Wolff [https://www.mediawiki.org/wiki/User:Bawolff Brian Wolff], MediaWiki Developer, Wikimedia (Wikipedia) Security team:
Inserting headers just because some website says so is silly - they should be investigated individually on their merits.
Website test sites like hardenize.com are helpful tools for website owners to check various security features, but these tests say little about the server's actual security. For instance, tests cannot check if: the kernel, operating system and web applications are fully up-to-date or neglected; SSH is configured for public key authentication only; the server is Kicksecure hardened; and whether backups are being made and so forth. For example, at the time of writing the Microsoft website recorded a "C" rating at securityheaders.com. Further, they did not have a CSP and neither DNSSEC nor DANE were configured. Despite this, the Microsoft website is not routinely hacked so malicious software can be uploaded by unauthorized third parties. * https://web.archive.org/web/20201213150857/https://www.hardenize.com/report/microsoft.com/1607820284 * https://web.archive.org/web/20201213145224/https://securityheaders.com/?q=microsoft.com&followRedirects=on As elaborated in the [[#Content Security Policy (CSP)|CSP]] entry on this page, the threat models are nuanced and {{project_name_short}} does not engage in security theater. While imperfections exist, reasonable efforts are made to improve website security despite constrained resources and developer time. A [[#Comparison_with_Others|Comparison of Test Results with Others]] also helps to put this information into perspective. [[Trust#Server_Security|Server security issues should not be conflated with software security issues]] and [[Trust#Server_Downtime|server downtime is not evidence of a server compromise]]. For further information on this topic, see [[#See_Also|here]]. {{Anchor|Whonix Test Results}} = {{project_name_short}} Test Results = '''Table:''' ''{{project_name_short}} Test Results'' {| class="wikitable" |- ! scope="col"| '''Test Site / Feature''' ! scope="col"| '''Result''' |- ! scope="row"| Email DANE | * https://www.hardenize.com/report/{{project_clearnet}}/1607868311
Email DANE (SMTP) DNS-based Authentication of Named Entities (DANE) is a bridge between DNSSEC and TLS. In one possible scenario, DANE can be used for public key pinning, building on an existing publicly-trusted certificate. In another approach, it can be used to completely bypass the CA ecosystem and establish trust using DNSSEC alone. Feature not implemented or disabled Your server doesn't support this feature.
The {{project_clearnet}} website does not offer free or paid email accounts. {{project_clearnet}} only uses email for these purposes: * sending emails to wiki editors who signed up to be notified about changes * forum email sign-up and notifications * developer accounts DANE should not be relied upon even if email security was perfect and all DANE tests were passed. It is far safer to use end-to-end encryption methods like [[OpenPGP]] or even better, [[codecrypt]]. |- ! scope="row"| hardenize.com | * https://www.hardenize.com/report/{{project_clearnet}}/1607868311 Forums: * [https://forums.whonix.org/t/no-clean-hsts-preload-dnssec/10255 no clean HSTS-Preload / DNSSEC] * [https://forums.whonix.org/t/expect-ct-security-header-for-whonix-org/10286 Expect-CT security header for {{project_clearnet}}] |- ! scope="row"| hstspreload.org | * https://hstspreload.org/?domain={{project_clearnet}} |- ! scope="row"| SSL Labs | * https://www.ssllabs.com/ssltest/analyze.html?d={{project_clearnet}} * pass * minor issue:
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
** 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. ** See [https://forums.whonix.org/t/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/5487/18 this]. |- ! scope="row"| Website DANE | See [[Dev/About_Infrastructure#DANE_TLSA|DANE TLSA References]]. Quote [https://forums.whonix.org/t/dane-tlsa-dns-based-authentication-of-named-entities-for-whonix-org/10218 DANE TLSA (DNS-based Authentication of Named Entities) for {{project_clearnet}}]:
For now decided not to implement it due to: * low adaption * no support in major browsers * complex, maintenance demanding setup
|- |} = Content Security Policy (CSP) = == Threat Model == In simple terms, a Content Security Policy (CSP) defines server instructions for what resources can be loaded by client browsers and from where. The [https://owasp.org/www-community/controls/Content_Security_Policy OWASP Foundation] provides more detail:
Is a W3C specification offering the possibility to instruct the client browser from which location and/or which type of resources are allowed to be loaded. To define a loading behavior, the CSP specification use “directive” where a directive defines a loading behavior for a target resource type. Directives can be specified using HTTP response header (a server may send more than one CSP HTTP header field with a given resource representation and a server may send different CSP header field values with different representations of the same resource or with different resources) or HTML Meta tag, the HTTP headers below are defined by the specs:
One use of a CSP is for web server software (like nginx) to tell the visitor's browser (such as Mozilla Firefox) what resources (like HTML, JavaScript and images) to load from which authorized sources. This is an interesting, nuanced threat model. At first sight it appears improbable that a CSP running on web server software can provide additional security for the software itself. However, modern web applications are very complex and prone to software bugs and security vulnerabilities. Consider the following example. A certain web application might not be functioning as expected due to a bug, or it may even be compromised because an attacker exploited an existing vulnerability. However, a compromised web application does not necessarily lead to a compromise of the web server software (like nginx), let alone a whole server (root) compromise. That is, the web server software might still function according to specifications. Under these conditions, a CSP can limit what the web application -- or more accurately, what the results of the output of the web application processed by the visitor's browser -- can do. For example, a CSP enforced by the web server software can prohibit The CSP is actually a recommendation for the browser. However, writing the following would be confusing:
For example a CSP enforced by the web server software can recommend the browser to not load content from external websites and the browser would honor this advice.
 the browser from loading content from third party websites. In some cases, web application vulnerabilities might be rendered completely harmless or made less useful due to a CSP's ability to contain faulty or compromised web applications. Of course it would be better to completely avoid faulty applications or compromises in the first place, but it is impossible to make this judgement in advance. Another good CSP use case concerns webmail, that is, reading email in a browser. For better security and privacy, all content from third party websites should be prohibited while content from the email provider is allowed. Even if this is in place, it is far safer to follow the {{project_name_short}} recommendation to [[E-Mail#Webmail|avoid webmail entirely]], and instead use an email client that has disabled all HTML and scripts (text-only mails). Forum discussion: [https://forums.whonix.org/t/content-security-policy-now-deployed-on-whonix-websites/5494 Content-Security-Policy now deployed on {{project_name_short}} websites] == {{project_name_short}} CSP == {{project_clearnet}} has an essential CSP. This is useful for the {{project_clearnet}} onion domain since it avoids loading resources from the {{project_clearnet}} clearnet domain and causing browser mixed content warnings. It is also helpful in avoiding clearnet connections for visitors who prefer the onion version of the {{project_name_short}} website. The reason is modern web applications are not designed for use on multiple domain names with the same database backend and/or for use with onion domains in general. However, {{project_clearnet}} does not yet have a CSP without 'unsafe-inline' and 'unsafe-eval' for all web applications:
* This policy contains 'unsafe-inline' which is dangerous in the script-src directive. * This policy contains 'unsafe-eval' which is dangerous in the script-src directive. * This policy contains 'unsafe-inline' which is dangerous in the style-src directive.
Users who have NoScript enabled in their browser are unaffected. Rather than relying on websites to deploy CSP, users should habitually use secure browsers, compartmentalize browsing in different virtual machines (VMs), [[System Hardening Checklist|harden]] their operating system, use [[Kicksecure]], and utilize NoScript. The widespread and perfect deployment of CSP is unlikely to happen soon, if ever. [[Kicksecure]] and [[Whonix]] are real efforts aimed at improving security and privacy; limited developer time and resources mean only reasonable efforts are focused on CSP at present. == {{project_name_short}} CSP Test Results == '''Table:''' ''{{project_name_short}} CSP Test Results'' {| class="wikitable" |- ! scope="col"| '''Domain''' ! scope="col"| '''Result''' |- ! scope="row"| Homepage | * [https://securityheaders.com/?q={{project_clearnet}}&followRedirects=on Quote securityheaders.com] for {{project_name_short}} website component, homepage. |- ! scope="row"| Forums | * [https://securityheaders.com/?q=forums.{{project_clearnet}}&followRedirects=on Quote securityheaders.com for {{project_name_short}} website component, discourse forums]. * CSP is implemented by the developers of the webapp, discourse. (Feature request for [https://meta.discourse.org/t/mitigate-xss-attacks-with-content-security-policy/104243/24 Discourse Forums Permissions-Policy].) * [https://securityheaders.com/?q=meta.discourse.org&followRedirects=on Quote securityheaders.com for upstream meta.discourse.org] |- ! scope="row"| Wiki | The following CSP is under consideration; it was previously enabled, so this advice is not current. [https://www.mediawiki.org/wiki/Manual:$wgCSPHeader $wgCSPHeader]
It is not compatible with $wgUseFileCache
Wiki users who are not logged in have 1 CSP, the essential CSP (by nginx). (Except for visitors of pages which are not yet cached.) Wiki users who are logged in have 2 CSPs, the essential CSP and on top of it the CSP generated by the mediawiki webapp setting $wgCSPHeader. * [https://phabricator.wikimedia.org/T270095 add Widgets extension compatibility with $wgCSPHeader CSP Content Security Policy] * [https://phabricator.wikimedia.org/T270099 add $wgCSPHeader CSP Content Security Policy compatibility with $wgUseFileCache file cache] * [https://securityheaders.com/?q=https%3A%2F%2Fwww.{{project_clearnet}}%2Fwiki%2FMain_Page&followRedirects=on {{project_name_short}} website component, wiki] * [https://securityheaders.com/?q=mediawiki.org&followRedirects=on securityheaders.com for upstream mediawiki.org] / [https://securityheaders.com/?q=wikipedia.org&followRedirects=on securityheaders.com for wikipedia.org] * [https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy#Multiple_content_security_policies Quote Mozilla Developer Network, Multiple content security policies]:
Adding additional policies can only further restrict the capabilities of the protected resource
|- |} = gzip = gzip is only relevant to performance and not security. To confirm, run [https://davidwalsh.name/check-gzip curl gzip test instructions]. {{CodeSelect|code= torsocks curl -H "Accept-Encoding: gzip" --head http://dds6qkxpwdeubwucdiaord2xgbbeyds25rbsgr73tbfpqpt4a6vjwsyd.onion/wiki/Documentation }} The output includes the following.
Content-Encoding: gzip
= Comparison with Others = Before making suggestions about features the {{project_clearnet}} website should implement, please conduct research on much better funded organizations for a fair comparison. Limited {{project_name_short}} resources make some features infeasible. See: * [https://www.hardenize.com/report/microsoft.com/1607820284 Microsoft, hardenize.com] * [https://securityheaders.com/?q=microsoft.com&followRedirects=on Microsoft, securityheaders.com] * [https://www.hardenize.com/report/torproject.org/1607868814#www_hsts The Tor Project, hardenize.com] * [https://securityheaders.com/?q=wikipedia.org&followRedirects=on Wikipedia, securityheaders.com] * [https://securityheaders.com/?q=mediawiki.org&followRedirects=on mediawiki.org, securityheaders.com] * [https://securityheaders.com/?q=https%3A%2F%2Fmeta.discourse.org&followRedirects=on Discourse, securityheaders.com] = See Also = * [[SSL|TLS]] * [[Server Security Guide]] * [[Privacy Policy Technical Details]] * [[Privacy_Policy_Technical_Details#Privacy_on_the_Kicksecure_Website|Privacy on the {{project_name_short}} Website]] * [[Trust#Trusting_the_Kicksecure_Website|Trusting the {{project_name_short}} Website]] * [[Trust#Distrusting_Infrastructure|Distrusting Infrastructure]] * [https://signal.org/blog/certifiably-fine/ Certifiably "F"ine] = Footnotes = {{reflist|close=1}} {{Footer}} [[Category:Documentation]]