Consider shipping SecureDrop directory via HTTPS Everywhere SecureDrop update channel

[redshiftzero]

Description

@Hainish had an interesting suggestion: to ship the SecureDrop directory in Tor Browser directly via a HTTPS everywhere SecureDrop ruleset channel.

We would:

1. Maintain a mapping of landing pages -> onion URLs (we already do this)
2. Create and sign a custom SecureDrop ruleset (with the SecureDrop release signing key)
3. Get our ruleset in Tor Browser (we'd be able to update them continuously)

At that point, when sources visit the landing page of the news organization, sources would be redirected to the onion URL of the SecureDrop that is listed in the ruleset.

@Hainish, let me know if I misunderstood anything or left out an important part.

See also relevant ticket on Tor Trac. Some initial thoughts follow:

Advantages

This is a mitigation for the threat of a news organization's web server hosting the SecureDrop landing page being compromised. With this change, if the web server is compromised and the onion URL has been replaced with a malicious one, if the source is visiting the landing page using Tor, then the source will be redirected to the correct onion URL regardless.

Indeed, once landing pages are in the SecureDrop ruleset, we could have organizations update landing page text to indicate that Tor Browser will redirect them to the correct SecureDrop onion URL (else sources that visit the landing page before switching over to Tor may still go to the attacker-controlled onion URL).

Once #2951 is completed (migration to v3 onion services), sources will need to type in a significantly longer onion URL (e.g. when copying the onion URL from a newspaper/billboard/flyer/etc.). This redirect would make the experience smoother from the source perspective.

Disadvantages

In the case where a news organization wants to cycle their onion URL, they must inform us rapidly and we must be in a position to quickly update the rulesets.

There is some potential user confusion when they get redirected to a potentially-scary-looking-onion URL. Without explanation, a user may think something is wrong.

User Research

We would need to do some user testing from a non-technical user perspective to scope the UX implications of these changes.

User Stories

As a SecureDrop source, I want getting to the SecureDrop source interface to be as smooth and easy as possible.

Subtasks

• add news organization main domain to securedrop.org directory API store URL of news organization main domain securedrop.org#675 (sprint 3/18-4/1)
• iterate as needed on initial ruleset channel for test purposes (can start with first version at https://redshiftzero.github.io/securedrop-httpse/ using scripts at https://github.com/redshiftzero/securedrop-httpse) (sprint 3/18-4/1)
• transition to production release key, more official URL, add alerts to regenerate/rerelease the channel upon directory changes (sprint 3/18-4/1)
• we test on our side in Tails since Tails is a recommended tool for sources (sprint 3/18-4/1)
• if upstream seems like they're going to make this official, we outreach to news orgs to see if there are concerns and if they want to opt-out
• provided upstream confirms this as the officially supported onion naming system, we will support it for SecureDrop instances and transition to an officially maintained channel. In that scenario we'll have a few followup actions (more might get added here):
  • add an opt-in button for news organization to elect to have themselves added to the directory in the securedrop.org instance verification form

[byeskille]

Interesting thoughts.

Just chiming in with some input from a news org:
The landing pages at the moment usually serve as more than a manual redirect to the source interface.
Most landing pages also contain guidance to potential sources regarding the news org, source protection, opsec advice etc.
This is also part of the recommended landing page setup in the docs.

With an automatic redirect this will be lost for users visiting via Tor Browser.
Then we would have to include such content at the source interface level in some way.

[Hainish]

Hey @redshiftzero, thanks for the write-up. Just a few clarifications:

2. Create and sign a custom SecureDrop ruleset (with the SecureDrop release signing key)

This should be an RSA key that's generated and airgapped, not (for instance) a PGP key. I'm assuming the SecureDrop signing key is a PGP key?

At that point, when sources visit the landing page of the news organization, sources would be redirected to the onion URL of the SecureDrop that is listed in the ruleset.

I was thinking something like /^https?:\/\/theintercept\.com\.securedrop\/?$/ would redirect to the onion URL for that SecureDrop instance. So instead of auto-redirecting from the landing page, creating a short URL with a pseudo-TLD to automatically forward.

This would also have the advantage of quick recovery in case of necessary key rotation - for instance if a particular instance's key is compromised or we have to rotate all instances keys again.

[conorsch]

@byeskille Brings up a great point about clear messaging for sources; in that respect, we may consider this work blocked by #3044.

[redshiftzero]

I'm assuming the SecureDrop signing key is a PGP key?

yep!

we may consider this work blocked by #3044.

well bill's comment above addresses the (legit) concerns raised by @byeskille - since the landing page will have a link to a URL of the .securedrop for that news organization

[Hainish]

I'm going to build out the CRUX UX for controlling update channels. For plausible deniability, it's obviously desirable if a SecureDrop update channel will be built into the Tor Browser build of HTTPS Everywhere. However this will allow us to do some testing and QA before the point where it's built into TB.

[redshiftzero]

At the latest hackathon, we (@emkll et al.) discussed a bit the security implications of this change, which are:

Advantages

• If we can remove the landing page entirely (as a place where the onion address is displayed for sources), it would mitigate all landing page related threats (Adversary hacks webserver hosting landing page, adversary observes traffic to subdomain, news organization has third party tracker on landing page, etc.). That said, there will always be a need for generic how-to-Tor instructions somewhere, and this will always be a place an adversary can monitor or hack, but perhaps that doesn't need to be directly on a news organization's site (this might not end up being practical). Abandoning the per-org landing page also would mean that there would not be a standard place to put pre-Tor OPSEC instructions for each organization, and there would be unified instructions for all SecureDrop instances which would basically be:

1. Ensure you are not using a monitored computer or an employer-controlled network.
2. Get Tor Browser.
3. Go to SecureDrop directory OR newsorg.com.securedrop if you know that you want to leak to a particular org.
4. At this point, the instructions made possible via the implementation of Enable administrators to edit all text on source interface #3044 would take over (we provide a reasonable default text, orgs should be able to customize).

• Prevents typosquatting of onion URLs or any attempts to generate vanity onion URLs - if it becomes standard practice to not directly use an onion address and instead have users use only the .securedrop pseudo-TLD, then this makes trying to get people to visit malicious onions significantly harder, as they would first need to get the malicious onion included in the custom ruleset.

New threats

These are new threats that we need to manage:

• Other rulesets can introduce a malicious .securedrop
• DNS requests to .securedrop pseudo-TLD are leaked - this can happen if a potential source visits the .securedrop prior to using Tor Browser. In addition, users may start attempting to navigate to newsorg.com.securedrop to determine whether or not the organization is using SecureDrop, which would also produce a DNS request. Note that for non-Firefox based browsers, this is currently the case for .onion addresses, and we can only partially mitigate this threat (by discouraging links to onion services on SecureDrop landing pages).
• Source freaked out/confused by redirect, discouraged from leaking - this is something that we need to do user research to scope.
• Sources trained not to check the onion URL - we encourage sources to cross-check the onion URL with e.g. the SecureDrop directory, or the physical newspaper/etc. where they found the onion URL to ensure that it is authentic. We know at least some sources are doing this.

[Hainish]

@redshiftzero
"* Other rulesets can introduce a malicious .securedrop" has always been true, also for .onion addresses. HTTPS Everywhere is already able to arbitrarily rewrite URLs in Tor Browser.

"* DNS requests to .securedrop pseudo-TLD are leaked" this can be mitigated by changing the URL to either [::1]/theintercept.com.securedrop or 0.0.0.0/theintercept.com.securedrop, since no DNS request is made for IP addresses. This will also remove the risk that currently exists of a Chrome user visiting the .onion address, which does send out a DNS request.

"* Sources trained not to check the onion URL" - I'm not certain why manually checking the onion URL would be necessary if we redirect via an update channel. This mitigates the threat of typo-squatters on .onion URLs, but if SecureDrop is the only entity (other than HTTPS Everywhere and Tor Browser itself, which is already the case) who can sign for .securedrop URLs and users are trained to leak via these URLs, that attack doesn't seem possible.

One additional advantage is that this will facilitate quick key rotation if needed (say a Heartbleed-style attack happens again or some subset of instances keys are compromised). Once the keys are rotated, the SecureDrop ruleset just has to be updated, signed, and posted. Within 24 hours all Tor Browser instances will have those rulesets. The next time a source visits 0.0.0.0/theintercept.com.securedrop they will be safely redirected to the new onion URL.

[Hainish]

I've documented the process of creating and maintaining update channels:

https://github.com/EFForg/https-everywhere/blob/master/docs/en_US/ruleset-update-channels.md

Note: anything mentioning scope in the documentation is implemented but not yet launched.

[Hainish]

I've added a corresponding issue on the Tor trac: https://trac.torproject.org/projects/tor/ticket/27551

[redshiftzero]

New ticket on Tor side about this: https://trac.torproject.org/projects/tor/ticket/28005

[ninavizz]

I really love this idea, but am curious: how many Sources is such a feature likely to reach? Do most Sources really use these sorts of tools, yet? How far has their reach extended outside the community of IFF geekery?

Again: I adore this idea... but it feels like a bit of a stretch to me, speculatively, that enough of a percentage of Sources would think to look for SD instances, there, for what it would cost to build this (vs other things Sources need).

Thoughts? Very open to learning about things I'm likely not seeing, in this.

ADDTL: If the gist of this feature is to enable something on the Tor side to do the equivalent of URL forwarding from memorable URLs to SD instances that would be easier for Sources to remember, THAT could be awesome. I may just not be understanding what I've read about this issue, too.

[redshiftzero]

Tor has made progress on this and has a PoC done in https://trac.torproject.org/projects/tor/ticket/28005

I've added suggested subtasks for us in the original post above. There's a first version of a SecureDrop-directory ruleset channel working using the scripts here. Channel for now is served at https://redshiftzero.github.io/securedrop-httpse/, signing pub key is at https://raw.githubusercontent.com/redshiftzero/securedrop-httpse/master/key.jwk.

For our next sprint after the beta workstation kicks off (3/18-4/1) we'll implement freedomofpress/securedrop.org#675, do some more testing and iterate on the rulesets as needed (and transfer the above repo to freedomofpress).

URL forwarding from memorable URLs to SD instances that would be easier for Sources to remember, THAT could be awesome

that's the idea exactly! Using the channel above one can type in something like www.buzzfeednews.com.securedrop.tor.onion (the specific URL is not decided upon yet, it may become shorter) and will get redirected to the corresponding onion URL. Since in SecureDrop 1.0 we moved to the v3 56 character onion URLs by default for new instances it's a big improvement.

[eloquence]

Next steps discussed at sprint planning today, for the 4/2-4/15 sprint:

• @redshiftzero will propose final URL schema
• @eloquence will draft a gentle opt-in ping to a few news orgs
• FPF infra will provide a lightweight hosting option for rulesets
• @redshiftzero will create and sign ruleset for news orgs that opt in, and publish manually
• This will still be an experimental deployment initially tested in Tor alpha builds.

[redshiftzero]

For posterity, recapping the URL schema options we discussed:

Option A - Recommended

We append .securedrop.tor.onion to the domain of the news organization.

Example 1:
theintercept.com becomes theintercept.com.securedrop.tor.onion

Example 2:
abc.net.au becomes abc.net.au.securedrop.tor.onion

Pros:

• Unique one-to-one mapping of current news organization domains to SecureDrop domains. - FPF does not need to maintain any special mapping other than the domain of their main news organization website.
• SecureDrops if they exist can be accessed from a predictable URL. This means that users in the future could append securedrop.tor.onion to see if an organization has a SecureDrop instance (or this can be done programmatically).

Cons:

• TLD is included in all cases, making the HTTPS Everywhere URL a bit longer.
• Additional complexity in recognizing subdomains (both redirect behavior and subdomain names vary), which may need to be resolved through common redirects (www.) or wildcard redirects (.) to the .onion address.

Option B

We append .securedrop.tor.onion to the domain of the news organization if the TLD of the news organization domain is .com, we omit it, else we include it as in option A.

Example 1:
theintercept.com becomes theintercept.securedrop.tor.onion

Example 2:
abc.net.au becomes abc.net.au.securedrop.tor.onion

Pros:

• Unique one-to-one mapping of current news organization domains to SecureDrop domains. FPF does not need to maintain any special mapping other than the domain of their main news organization website.
• For most news organizations since they use the .com TLD, the TLD is not included, making the URLs shorter.

Cons:

• Inconsistent handling of the TLD, making the URLs hard to predict unless one is familiar with the scheme when accessing non .com SecureDrops.
• Additional complexity in recognizing subdomains (both redirect behavior and subdomain names vary), which may need to be resolved through common redirects (www.) or wildcard redirects (.) to the .onion address.

Option C

We maintain a mapping ourselves, and never include the TLD.

Example 1:
theintercept.com can become theintercept.securedrop.tor.onion or even intercept.securedrop.tor.onion

Example 2:
abc.net.au can become abc.securedrop.tor.onion

Pros:

• Shortest URLs.

Cons:

• FPF needs to maintain this mapping, and deal with the fact that organizations may get desired .securedrop.* URLs before others (e.g. the owner of abc.net.au could get abc.securedrop.tor.onion before abc.com potentially leading to significant confusion from users).

We decided to go with option A for now.

Status

We made an officially signed version with only orgs that have opted-in to the ruleset, and thanks to team infra we have our official ruleset deployed on https://securedrop.org/https-everywhere/.

Further suggestions should go as tickets in https://github.com/freedomofpress/securedrop-https-everywhere-ruleset, closing this ticket for now.

If you are a news org viewing this and want to be onboarded and you haven't had a message yet in the support portal, please file a ticket in support.freedom.press.

We're instructing people not to advertise these URLs yet to sources as this is still experimental.