{{Header}}
{{#seo:
|description=Technical Details on some of the Technical Measures by {{project_name_long}} to increase privacy and security on {{project_clearnet}}.
|image=Privacypolicy.jpg
}}
{{legal_documents}}
{{intro|
Technical Details on some of the Technical Measures by {{project_name_short}} to increase privacy and security on {{project_clearnet}}.
}}
'''See also [[Privacy Policy]].'''
'''These technical details are not part of [[Privacy Policy]].'''
= Overview =
{| class="wikitable"
!Security / Privacy Feature
!Implementation Status
|-
|Valid SSL Certificate
|{{Yes}}
|-
|HTTPS Everywhere [https://www.eff.org/https-everywhere] Inclusion
|{{Yes}} [https://gitlab.torproject.org/legacy/trac/-/issues/9143]
|-
|Passed Qualys SSL LABS [
https://www.ssllabs.com/
] SSL Server Test [
https://www.ssllabs.com/ssltest/index.html
]:
|{{Yes}}, A+ rating. [
https://www.ssllabs.com/ssltest/analyze.html?d={{project_clearnet}}
]
|-
|HSTS [https://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security]
|{{Yes}} [
{{CodeSelect|code=
curl -i https://{{project_clearnet}}
}}
]
|-
|HSTS Preloading List [
https://blog.chromium.org/2011/06/new-chromium-security-features-june.html] [
https://blog.stalkr.net/2011/08/hsts-preloading-public-key-pinning-and.html
] [
https://www.chromium.org/hsts/] [https://blog.mozilla.org/security/2012/11/01/preloading-hsts/
] [
https://bugzilla.mozilla.org/show_bug.cgi?id=861960
]
| {{Yes}} [
https://web.archive.org/web/20201214130859/https://github.com/Whonix/Whonix/issues/34] [
https://src.chromium.org/viewvc/chrome?revision=209444&view=revision
] [
https://hstspreload.org/?domain={{project_clearnet}}
]
|-
|Certificate Authority (CA) Pinning
|Obsolete [https://phabricator.whonix.org/T66]
|-
|DNS Certification Authority Authorization (CAA) Policy [
https://blog.qualys.com/ssllabs/2017/03/13/caa-mandated-by-cabrowser-forum
]
|{{Yes}} [
https://forums.whonix.org/t/dns-certification-authority-authorization-caa-policy-dnssec-for-{{project_name_short}}-org-ssllabs-com-test-results/5487
]
|-
|HTTP Public Key Pinning [https://developer.mozilla.org/en-US/docs/Web/Security/Certificate_Transparency]
|Obsolete [
https://phabricator.whonix.org/T84
]
|-
|Expect-CT header [https://scotthelme.co.uk/a-new-security-header-expect-ct/]
|{{Yes}} [
* https://forums.whonix.org/t/dns-certification-authority-authorization-caa-policy-dnssec-for-{{project_name_short}}-org-ssllabs-com-test-results/5487/2
* https://forums.whonix.org/t/expect-ct-security-header-for-whonix-org/10286
]
|-
|certspotter [https://github.com/SSLMate/certspotter]
|{{Yes}} [https://forums.whonix.org/t/dns-certification-authority-authorization-caa-policy-dnssec-for-{{project_name_short}}-org-ssllabs-com-test-results/5487/2]
|-
|DNSSEC [https://en.wikipedia.org/wiki/Domain_Name_System_Security_Extensions]
|{{Yes}} [https://forums.whonix.org/t/dns-certification-authority-authorization-caa-policy-dnssec-for-{{project_name_short}}-org-ssllabs-com-test-results/5487]
|-
|Flagged Revisions [https://www.mediawiki.org/wiki/Extension:FlaggedRevs]
|{{Yes}}, admins must verify changes before they become the default version.
|-
|Content Security Policy (CSP)
|{{Yes}}, A Rating. [
https://securityheaders.io/?followRedirects=on&hide=on&q={{project_clearnet}}
] [
https://phabricator.whonix.org/T70
] [
https://forums.whonix.org/t/whonix-website-security-rating-b-mozilla-observatory-content-security-policy-csp/3874
] [
https://forums.whonix.org/t/content-security-policy-now-deployed-on-{{project_name_short}}-websites/5494
]
|-
|Feature-Policy
|{{Yes}}
|-
|Secondary .onion Domain [Optional Tor onion service (].onion domain); alternative [[Onion_Services#Notes_about_End-to-end_Security_of_Onion_Services|end-to-end encrypted/authenticated connection]]; in this use case, not for location privacy; backup in case DNS is not functional.
|{{Yes}} [
{{CodeSelect|code=
{{project_onion}}
}}
] [
See also [[Forcing .onion on Project|Forcing .onion on {{project_name_short}}.org]].
]
|-
|Onion-Location [
https://community.torproject.org/onion-services/advanced/onion-location/
]
|{{Yes}} [
https://forums.whonix.org/t/onion-forum-site-redirects-to-clearnet/197/15
]
|-
|onion over TLS
|[[#Onion TLS on the {{project_name_short}} Website|Unnecessary]].
|-
|}
If users have any further suggestions, please edit this entry or discuss possible changes in the {{project_name_short}} forums.
* SPF - https://dmarcian.com/spf-survey/?domain={{project_clearnet}}
* DKIM - https://dmarcian.com/dkim-inspector/?domain={{project_clearnet}}&selector=default
* DMARK - https://dmarcian.com/dmarc-inspector/?domain={{project_clearnet}}
* BIMI - https://mxtoolbox.com/SuperTool.aspx?action=bimi%3A{{project_clearnet}}&run=toolpage
* https://www.digitalocean.com/community/tools/dns?domain={{project_clearnet}}
{{Anchor|website}}
{{Anchor|Privacy on the Website}}
= Privacy on the {{project_name_short}} Website =
The {{project_name_short}} website [
Clearnet address:
{{CodeSelect|code=
https://www.{{project_clearnet}}
}}
v3 onion address:
{{CodeSelect|code=
{{project_onion}}
}}
] is using popular web applications (web apps) like [https://www.mediawiki.org/wiki/MediaWiki MediaWiki],and [https://www.discourse.org/ Discourse] (forum software). [
This is common practice. For example [https://www.fsf.org/blogs/membership/introducing-our-new-associate-member-forum Free Software Foundation (FSF) also uses discourse.]
] These are Freedom Software projects which are developed by third parties and not the {{project_name_short}} team. As an end user of web apps, {{project_clearnet}} has no control over changes made by the respective developers, whom do not necessarily (seldom in fact) prioritize privacy and security.
The {{project_name_short}} platform is similarly based on many third party projects. For a simple (approximate) overview of the {{project_name_short}} organizational structure, see: [[Linux_User_Experience_versus_Commercial_Operating_Systems|Linux User Experience versus Commercial Operating Systems]]. In essence, many independent projects provide their software and source code for free, and they can be modified or used in their default state. Due to the [[#Software Comparison|structure]] of Freedom Software development and the limited [[#Funding Comparison|funding]] available to {{project_name_short}}, it is infeasible to try and tackle usability, privacy and security issues posed by these web apps.
Consider the Discourse software for example:
* Google is used as the default search engine, even though it would be far preferable to configure another search engine which respects privacy. {{project_name_short}} developers posted a [https://meta.discourse.org/t/feature-request-configurable-search-engine-for-forum-search/35793 Feature request: configurable search engine for forum search], but discourse developers in essence replied "patches welcome".
* [https://forums.whonix.org/t/moderating-threads-moving-editing-does-not-always-funtion-properly/6334/6 Discourse does not work well with secondary onions].
* [https://meta.discourse.org/t/email-less-and-password-less-registration-authentication/207737/19 Discourse has no feature to easily permit sign-up without an e-mail address.]
* Discourse does not work great without JavaScript. Related: [https://forums.whonix.org/t/turn-off-javascript-in-whonix-forums/1692 Turn off Javascript in Whonix Forums]
{{project_name_short}} is primarily a software project. It uses web applications as a means to and end. Not as an end in itself. It is not a web application project.
Based on the preceding information, it is clear websites can at best only provide privacy by policy, which is equivalent to a promise. For detailed information on the {{project_name_short}} privacy policy, see [[Privacy Policy|here]]. [
This includes any type of information that is collected and recorded, and how it may be used. The processing of any personal information is subject to the General Data Protection Regulation (GDPR).
]
In contrast, the [[What we do|main project activities]] undertaken by {{project_name_short}} include research, development and maintenance of [https://github.com/{{project_name_short}} privacy by design software]. This is achieved via technological enforcement, [[Reasons for Freedom Software|remaining free]], [
Free in terms of price, while also respecting user and developer freedoms.] and utilizing Freedom Software which encourages external contributions, enhancements and audits.
{{mbox
| type = notice
| image = [[File:Ambox_notice.png|40px|alt=Info]]
| text = {{project_name_short}} [[Reporting_Bugs#Patches are Welcome|welcomes patches]] or [[Donate|financial contributions]] to support the development of desired features.
}}
See also [[Trust#Trusting_the_{{project_name_short}}_Website|Trusting the {{project_name_short}} Website]] and [[Website Tests]].
= View Counters on the {{project_name_short}} Website =
View counter in the {{project_name_short}} wiki have been disabled to reduce server load and because that is incompatible with caching.
View counters in {{project_name_short}} forums were inaccurate and have therefore been disabled on 09 April 2021. [
* https://meta.discourse.org/t/custom-css-for-removing-view-count-bar/74581/6
* https://meta.discourse.org/t/custom-css-for-removing-view-count-bar/74581/9
* https://meta.discourse.org/t/disable-click-counts/146622/2
]
Since all webapps running the {{project_name_short}} server lack access to IP addresses (for details see, [[Privacy Policy|{{project_name_short}} Website privacy policy]], [[Privacy_Policy#IP_Addresses_and_IP_Addresses_Logging_Policy|{{project_name_short}} Website IP Addresses and IP Addresses Logging Policy]]), it is impossible for these webapps to accurately count for example how many times a wiki page has been visited or how many times a forum post has been viewed.
= Social Share Button =
There are no privacy issues caused by any share buttons on the {{project_clearnet}} website. We don't use embedded scripts. The share button is completely self-hosted by this webserver. No scripts from any of the social networks are embedded on this webserver. See also [[Privacy Policy]].
A bit of background how this generally works on many other websites. Many websites using share buttons for social networks are using the integration scripts provided by the social network. For example, to add a Facebook share button, many website administrators are using the JavaScript provided by Facebook. These scripts are usually non-freedom software and only stubs. Meaning, these scripts point to the social network such as Facebook and instruct the users's browser to download and execute even more non-freedom JavaScript, html and images. By visiting a website with such a share button, the social network knows that the user was visiting that website. Due to the script by a third-party, the social network, the social network could even perform browser fingerprinting, set browser cookies and so forth. Clearly such third-party hosted share button integrations have many privacy issues.
The advantage is that these buttons are interactive. For example, a user can see how many times something has already been shared and after pressing the share button, the counter increases or the counter increasing can even be watched live.
Since these advantages are rather playful, minor, the {{project_clearnet}} project decided do not add any third-party hosted scripts. Unless the user clicks a share button for a specific social network, that social network will get no information about the user. There source code for the share button on this website is Freedom Software. ([[Dev/mediawiki#Share_Tooltip|Share Button Source Code]])
'''Figure:''' ''Share Button''
Share button requires JavaScript.
{{Anchor|onion-tls}}
{{Anchor|Onion_TLS}}
= Onion TLS on the {{project_name_short}} Website =
Would raise the question: use HSTS or not use HSTS for Onion TLS?
Does Tor Browser support HSTS? [https://gitlab.torproject.org/legacy/trac/-/issues/17965 Looks like, yes].
* If not using HSTS: If the user's browser is not instructed to enforce TLS, then what's the point?
* If using HSTS: That has potential to break connectivity when there are issues with the TLS Certificate Authority (CA), such as:
** CA goes out of business.
** CA terminates the services.
** CA starts charging for the service.
** (Legislation changes and) CA starts asking for things which cannot be provided with reasonable effort.
This issue is exacerbated since there is at the of writing only 1 CA that is offering affordable TLS certificates for onion domains, HARICA. (In future, specifically let's encrypt might offer the same and/or others might follow. But that's not the case yet.)
If required at some point for any reason, a downgrade from TLS-onion to non-TLS-onion downgrade would look bad.
There are two different systems.
* '''A)''' The "normal" internet. The usual top level doamins, .com, .org, etc. It is a centralized, permissioned system. The same applies for CA's.
* '''B)''' The "alternative" internet. For example .onion domains. decentralized, permissionless system. Anyone can set up an .onion without asking a central authority for permission.
Simplified: Connections to onions are already authenticated and end-to-end encrypted. (Details: {{whonix_wiki
|wikipage=Onion_Services#Notes_about_End-to-end_Security_of_Onion_Services
|text=Notes about End-to-end Security of Onion Services
}})
Using onions with a TLS certificate from a CA could be viewed as a downgrade. A decentralized, permissionless system is downgraded to a centralized, permissioned system.
{{project_name_short}} Website is currently using let's encrypt. Server setup would become more complex by adding another CA, HARICA. The advantages do not outweigh the disadvantages.
Quote [https://blog.torproject.org/tls-certificate-for-onion-site/ Get a TLS certificate for your onion site]:
Our Community portal page about onion services give you a list of reasons why a service admin would need a TLS certificate as part of their implementation. Here are some of them:
* Websites with complex setups and that are serving HTTP and HTTPS content
Not the case.
* To help the user verify that the .onion address is indeed the site you are hosting (this would be a manual check done by the user looking at the cert registration information)
Answered below (see 2.).
* Some services work with protocols, frameworks, and other infrastructure that has HTTPS connection as a requirement
In case your web server and your tor process are in different machines
Not the case.
Quote [https://community.torproject.org/onion-services/advanced/https/ We compiled some topics and arguments, so you can analyze what's the best for your onion site:]
1. As anyone can generate an onion address and its 56 random alphanumeric characters, some enterprise onions believe that associating their onion site to an HTTPS certificate might be a solution to announce their service to users. Users would need to click and do a manual verification, and that would show that they're visiting the onion site that they're expecting. Alternatively, websites can provide other ways to verify their onion address using HTTPS, for example, linking their onion site address from an HTTPS-authenticated page, or using Onion-Location.
Already using [https://community.torproject.org/onion-services/advanced/onion-location/ Onion-Location].
2. Another topic of this discussion is user expectations and modern browsers. While there is extensive criticism regarding HTTPS and the CA trust model, the information security community has taught users to look for HTTPS when visiting a website as a synonym of secure connection and avoid HTTP connections. Tor Developers and UX team worked together to bring a new user experience for Tor Browser users, so when a user visits an onion site using HTTP [https://support.torproject.org/onionservices/onionservices-5/ Tor Browser doesn't display a warning or error message].
Visitors using the onion are expected to use Tor Browser anyhow which as already mentioned in the quote, does not have this issue.
3. Some websites have a complex setup and are serving HTTP and HTTPS content. In that case, just using onion services over HTTP could leak secure cookies. We wrote about Tor Browser security expectations, and how we're working on onion services usability and adoption. There are some alternatives you might want to try to address this problem:
* To avoid using an HTTPS certificate for your onion, the easiest answer is to write all your content so it uses only relative links. Then the content will work smoothly no matter what website name it's being served from.
This is implemented.
* Another option is to use webserver rules to rewrite absolute links on the fly.
This is implemented.
* Or use a reverse proxy in the middle or more specifically EOTK with an HTTPS certificate.
Not needed.
4. Actually HTTPS does give you a little bit more than onion services. For example, in the case where the webserver isn't in the same location as the Tor program, you would need to use an HTTPS certificate to avoid exposing unencrypted traffic to the network in between the two. Remember that there's no requirement for the webserver and the Tor process to be on the same machine.
Not the case for {{project_name_short}} website. It does not require such a complex setup yet.
This might be revisited at a later point need arises and/or when Onion TLS support improved.
Quote https://github.com/alecmuffett/real-world-onion-sites#tls-security
'''TLS Security'''
Due to the fundamental protocol differences between HTTP and HTTPS, it is not wise to consider HTTP-over-Onion to be “as secure as HTTPS”;
This is a very browser focused viewpoint. That's legitimate because browsers are probably the most popular internet application people are using.
* connection security: Onion is more secure than [[SSL|TLS]]. Onion's aren't vulnerable to [[SSL#The Broken Certificate Authority System|The Broken Certificate Authority System
]], [[SSL#Compromised Certificate Authorities|malicious CA authorities]], [[SSL#TLS Attacks|TLS related attacks]]. Note: in this context of onion transport security, attacks on onion's anonymity are unrelated. To the knowledge of the author, to contents of a client connection to an onion have never publicly reported being compromised because of broken Tor onion cryptography. Onion encryption versus TLS can also be considered for applications other than browsers.
* application security: The author raises valid concerns.
web browsers '''do''' and '''must''' treat HTTPS requests in ways that are fundamentally different to HTTP, e.g.:
* with respect to cookie handling, or
* where the trusted connection terminates, or
* how to deal with loading embedded insecure content, or
* whether to permit access to camera and microphone devices (WebRTC)
Valid concern. Mitigated using CSP. Unfortunately CSP is only a server feature. Server instructs browser to fetch only from onion and no mixed content. A browser based security feature enforcing TLS independent from CSP would be stronger.
Since it is difficult to configure many popular web applications to be available on two domains (clearnet and onion) at the same time, it happened in the past on this website that some contents were unavailable over the onion. For example, the project logo was only visible on the clearnet version but not over the onion. The CSP was functional and avoided any content mixing of the onion with contents pointing to clearnet.
…and the necessity of broad adherence to web standards would make it harmful to attempt to optimise just one browser (e.g. Tor Browser) to elevate HTTP-over-Onion to the same levels of trust as HTTPS-over-TCP, let alone HTTPS-over-Onion. Doubtless some browsers will ''attempt'' to implement “better-than-default trust and security via HTTP over onions”, but this behaviour will not be '''standard''', cannot be '''relied upon''' by clients/users, and will therefore be '''risky'''.
This depends on the complexity of the implementation. Tor Browser can hopefully use the same code paths. [
Pseudo code, hopefully, needs further research.
* Most browsers:
]
insecure protocols = http
secure protocols = https
* Tor Browser:
insecure protocols = http
secure protocols = https, onion
'''tl;dr''' - HTTP-over-Onion should not be considered as secure as HTTPS-over-Onion, and attempting to force it thusly will create a future compatibility mess for the ecosystem of onion-capable browsers.
= HSTS Warning =
'''Figure:''' ''TLS HSTS failure''
[[File:TLS_HSTS_failure.png|470px]]
This could have many reasons.
* A) '''server issue:''' A server configuration issue or server bug. And/or,
* B) '''browser issue:''' A browser bug. And/or,
* C) '''attack:''' An actual man-in-the-middle (MitM) attack.
If the issue is transient, the only thing that users can effectively do is report it and then ignore it. So far there was only 1 such report in 12 years.
Meanwhile, if this issue persists for a longer time, the user could use the alternative onion domain.
If this is an actual MitM attack, then there is most likely nothing the website can do about it, since it would not be the cause of the issue.
= See Also =
* [[SSL|TLS]]
* [[Website_Tests|Website Tests / Server Tests]]
* [[Privacy Policy]]
= Footnotes =
{{reflist|close=1}}
{{Footer}}