Build a comprehensible onionsite checklist/documentation

Tasks

• Create a wiki page for a public Onion Service site checklist/documentation. Done as Service-Checklist.
• Move part (if not all) of this documentation to the the Onion Service "portal", to the upcoming Developer Portal, to separate page, or to the ecosystem docs web checklist. Moved to the latter.
• Write a comprehensible and public Onion Service site checklist/documentation.
• Split or tag items as "must have", "nice to have", "could have" or something in the line of the MoSCoW method.
• Once the checklist is ready, remove the not atop of the ecosystem docs web checklist that says it is still being written.

Contents

Documentation might including topics like:

• Setting up:
  • Example with Apache (and remark about UNIX sockets not being supported).
  • Example with NGINX (TCP and UNIX sockets).
  • Example with lighttpd (and note about UNIX sockets support).
  • Example with Caddy (does it support UNIX sockets?).
• Best practices:
  • The slightly outdated but very good Riseup documentation about Hosting Onion Services.
  • Relay security checklist (if exists), since the Onion Service checklist could be built atop of more general checklists about running a Tor node (but with the warning that no relay should run along the Onion Service instance).
  • See existing and legacy docs like the legacy OperationalSecurity page.
  • Making sure the system clock is synchronized.
  • Setup the Onion Location header (for sites accessible also from outside the Tor network).
  • Encrypted backup of .onion keys.
  • Consider NOT to use single mode/non-anonymous Onion Services (HiddenServiceSingleHopMode and HiddenServiceNonAnonymousMode) if distinct sites are hosted in the same provider/virtual machine and if relating each other is a concern. Like, suppose many distinct sites have their onions at the same place. Using single mode would mean it's easy to determine that these sites have their .onions hosted in the same location. By default HiddenServiceSingleHopMode and HiddenServiceNonAnonymousMode are not set, but depending on the tooling used to deploy this might not be the case.
  • Where to put the onion service webserver socket.
• Optional/Advanced:
  • Load balancing:
    • Introduction (reusing part of the existing Onionspray documentation about load balancing: introduction and topologies).
    • Setting up Onionbalance:
      • Consider that using Onionbalance is also a measure for protecting the main Onion Service keys, as compromised backends would not expose the main keys. Check upcoming security analysis for details.
  • Configure Vanguards on each backend.
  • Vanity address generation (using mkp224o or other compatible tools)?
  • Setup HTTPS with valid x509 certificates (and automatic HTTP -> HTTPS connection upgrade, like with automatic HTTP-to-HTTPS redirection and/or the HSTS header).
  • Setup Onion Names (HTTPS Everywhere patch, or whatever is on it's place).
  • Onion v3 auth (current unsupported by Onionbalance, see tpo/core/onionbalance#5).
  • Alt-Svc Header (as an alternative or compliment to the Onion-Location header).
  • Iframe handling (referrerpolicy etc). References:
    • Redact onion origins from Location.ancestorOrigins. (#44801) · Issue · tpo/applications/tor-browser
    • Review Mozilla 1085214: Implement Location.ancestorOrigins (#44731) · Issue · tpo/applications/tor-browser
    • The Inline Frame element - HTML | MDN
      • Same-origin policy - Security | MDN
    • 1085214 - Implement Location.ancestorOrigins
      • HTML Standard
        • HTML Standard
          • HTML Standard
    • Location: ancestorOrigins property - Web APIs | MDN
      • Location: ancestorOrigins - Web APIs
• Performance:
  • Assets: consider to provide image, video and other assets optimally compressed to alleviate bandwidth comsumption in the Onion Service. While this is a general recommendation for any site, this can be of special importance for Onion Services. It might be worth checking browser support for storage-efficient formats (see tpo/applications/tor-browser#41664 (closed) for a discussion example).
• Hardening:
  • Adapt some tables from Onion Services in the Wild: A Study of Deanonymization Attacks (in anonbib as @pets24-onions). Maybe these tables should be in the Security page instead, but anyway both pages can be mutually linked:
    • Table 10: Essential advice for Tor beginners (page 309). Done.
    • Table 11: Advanced security practices for experienced Tor users (page 310).
    • Table 12: Advice for Onion Service Operators (page 310).
    • Report back to the authors.
  • Add a reference to Hardening Tor Hidden Services thesis (maybe in the anonbib as @tippe2022) (direct PDF link).
• Risk analysis:
  • De-anonymization:
    • This great analysis from Vanguards.
    • Detecting/correlating online/offline patterns.
    • Server fingerprinting.
• Metrics:
  • Using the MetricsPort (and/or a web panel):
    • Locally (as usually recommended).
    • Or through an authenticated .onion to enable remote monitoring? Which plugin could be used by Prometheus to fetch data from such a service? Example Prometheus configuration.
• Tuning and Quality Assurance tips (moved from #12 (closed)):
  • Add a reference to Onionsec (repository, UI repository).
  • Document tuning tips, like:
    • Using Brave and Lighthouse:
      • https://github.com/GoogleChrome/lighthouse
      • https://developer.chrome.com/docs/lighthouse/overview/
    • Similar profiling tool for Tor Browser?