Set Onion-Location header

[eloquence]

securedrop.org has a corresponding onion service (v2 for now). We should advertise it via Onion-Location, which Tor Browser 9.5 will interpret to show an ".onion available" button.

https://community.torproject.org/onion-services/advanced/onion-location/

Example screenshot:

[chigby]

Do we have the address of the onion service? Is that something that's okay to post in this issue?

[conorsch]

Currently it's secrdrop5wyphb5x.onion, also available in the footer of securedrop.org prod. Perhaps too much information: secrdrop5wyphb5x.onion is a v2 Onion URL, and we aim to transition soon to a v3 Onion URL, such as sdolvtfhatvsysc6l34d65ymdwxcujausv7k5jk4cy5ttzhjoi6fzvyd.onion. The v2 Onion secrdrop5wyphb5x.onion currently requires to HTTPS with an EV cert, but with the v3 version, we don't have an HTTPS cert yet, and may never add support for it.

Assuming you wire up a settings-based config where ONION_URL env var results in the Onion-Location header being served, I'm pretty sure we can safely override it later to update.

[chigby]

Thanks for that information, Conor. I can definitely wire up the settings as you describe.

Though, I wonder, now, if the best way to take an env var and serve it out as a header is at the nginx level, rather than at the Django level? Though there might be other issues involved in that I'm not aware of.

[conorsch]

I admit my kneejerk reaction is that HTTP header manipulation is best handled via nginx, rather than at the app-code layer. For the CSP, though, we're injecting headers via app code settings, and that makes lots of sense. One nice feature of preferring app code for managing the logic is that via containerization, no infra involvement would be required to update the options, web team could own it fully. Perhaps that's a bit of a moot point, given that the underlying keypair for the Onion service is still managed in infra secrets somewhere...

@harrislapiroff What do you think? My preference is always to enable web team to manage as much as possible directly, but if for pragmatic reasons y'all would prefer that infra manage the Onion logic, happy to accommodate.

[harrislapiroff]

One thing not mentioned yet: Is there any reason not to make it something that can be customized from the Wagtail admin? Are we concerned about bad actors getting db or admin access more easily than env access? (Though we do also host GPG public keys and our crypto wallet addresses in the database—and I believe infra has integrity checks for the latter—which seems reasonably analagous.)

I do think I'd prefer to see this as django middleware rather than nginx logic for the portability reasons @conorsch mentioned.

[conorsch]

Nice, I really like the suggestion of supporting interactions via Wagtail admin, so that even more folks than infra & web can manage the header. No concerns there security wise, if folks have access to the admin interface on e.g. SDO, they already have the ability to do a lot of damage by updating directory entries etc.

[conorsch]

Not seeing the "onion available" notification in Tor Browser 9.5, even after this change was deployed:

The header is being served:

$ torify curl -sI https://securedrop.org | grep -i onion
onion-location: secrdrop5wyphb5x.onion

but the value doesn't quite match the spec (emphasis added):

The Onion-Location value must be a valid URL with http: or https: protocol and a .onion hostname.

So what we want to see is something like:

$ torify curl -sI https://securedrop.org | grep -i onion
onion-location: https://secrdrop5wyphb5x.onion

Given that there are at least two places where the Onion value is used, i.e. Onion-Location header & in the footer, maybe some additional formatting is warranted. But as currently implemented, we don't have the functionality we want to consider the issue resolved.

[harrislapiroff]

Sorry, should have mentioned in chat that we can add the protocol in the admin under footer settings! Any reason we wouldn't want the protocol in both places?

[conorsch]

Well I'll be: that was simple enough. After making the manual edit in the admin panel, both the footer shows the https prefix (not strictly required, but not a problem), and more importantly the header is indeed serving well.

Thank you for clarifying, @harrislapiroff!