[Feature proposal] Verification of onion service integrity

Problem statement

SecureDrop and similar onion services that seek to provide end-to-end-encrypted communications (between sender and designated recipient) have a bootstrapping problem: if the server is compromised, users cannot be sure that their communications are in fact end-to-end encrypted. Server-provided code or cryptographic key material may have been tampered with.

This is not addressed by existing web standards like SRI and CSP, both of which depend on the server being a trusted resource to begin with. In the context of WhatsApp E2EE, Cloudflare/Facebook have recently piloted the use of an integrity verification browser extension.

We similarly need a way to securely ship authenticated JavaScript and WASM code and ensure that script execution is limited to that resource(s) only.

The executed code would be the same for all SecureDrop instances of the same version. This requirement is both to prevent browser exploits from untrusted sites and from trusted but compromised websites, as well as to prevent MITM attacks from trusted but compromised websites.

Proposal

We suggest that an integrity verification feature can be built on top of the existing about:rulesets functionality in Tor Browser, which maps full-length onion addresses against short names in the form <service-name>.<namespace>.tor.onion, e.g., nytimes.securedrop.tor.onion, and ships this information as a signed ruleset.

In this proposal, a ruleset provider could act as a verifier of a set of hashes (e.g., sha-256) which correspond to accepted response bodies for specific paths, e.g., /index.html, /1.0.0/. Subresources could then be verified using SRI.

Tor Browser would need to compute the hash based on the decompressed response body, before rendering the page, and display an error message if it does not correspond to one of the accepted hashes.

Interactions with Tor Browser's safety settings and the NoScript extension will need to be considered; ideally we'd like to ensure script execution is limited to resources that are verified directly or indirectly (e.g., via SRI hashes in a verified resource).

Alternatives and implementation

We’d be happy to discuss alternative approaches that seem like a better fit from the Tor Project’s perspective, and are open to partnering directly with you on the implementing, testing and piloting any agreed upon approach.