[v3 onion migration] investigate v2-only user messaging options

[redshiftzero]

Description

This is a stretch ticket for #2951.

For organizations enabling v2 and v3 alongside (expected for most existing SecureDrop instances) we’d ideally expose to source and journalist users something like:

“Warning: you are currently using 0123456789abcedf.onion, in the future please use our new improved onion (language here intentionally vague because we’re not going to take on the task of explaining the detailed differences of v2 versus v3 onions to non-technical users - could be something like “more secure”!) at <long address>.onion.”

This ticket is to investigate methods to do this. While we could defer this until a future release, it would be wise for us to use some cycles now to think about this now in case we need Apache config changes to pass through v2/v3 info - it’s potentially brittle to make this kind of change in an auto update.

[conorsch]

Inside the Flask app, we can inspect the Host request header to determine whether the user-facing message should be displayed, but we cannot inspect the Alt-Svc response header (even if set), so we cannot easily recommend the v3 URL—i.e. "at .onion" in the example message above—without further changes.

Two possible solutions:

• read the alt-svc declaration from the apache config and retrieve the URL; brittle
• store the Onion URL info on the server in machine-readable format so we can look it up (see [v3 onion migration] If v2 and v3 are both used, set Alt-Svc header in Apache configs #4630 (comment))

Preference is for 2). Thoughts, @redshiftzero?

[redshiftzero]

yep I like 2, so the plan would be:

1. when v3 is enabled we write the hostname also to a new file in /var/lib/securedrop/ readable by www-data (we implement this for 1.0.0)
2. in a future PR we can then inspect the Host header via request.headers.get('Host'), and we can even just use the length (if 16 character + .onion then v2, else if 56 character + .onion it's v3), to show message "please use .onion in the future" (exact message TBD). This step is for a future release when we deprecate v2 onions but we'll have all the pieces in place to do so.

[conorsch]

After discussing with @redshiftzero, we'll go with option 1 above. Specifically, we want to deliver:

• A plaintext file in /var/lib/securedrop/ for the source v2 Onion URL (if exists)
• A plaintext file in /var/lib/securedrop/ for the source v3 Onion URL (if exists)
• Ensure files readable by www-data
• Config tests to verify the files are present in CI runs

We don't plan to implement any custom messaging as part of the 1.0. If we deliver the changes to expose the URL info to the application, then we're unblocked adding such messaging in the future, without requesting Admin intervention in the form of playbook runs.