[scanner integration] Check integration plan against a threat model for landing pages

[eloquence]

As part of epic #488, we should ensure that the proposed "moderate" and "severe" warnings, and the proposed addition of remaining known instances to the SecureDrop directory, are consistent with a reasonable threat model for sources.

The current plan makes several assumptions:

• that if a security issue is truly egregious (e.g., no HTTPS on landing page), a SecureDrop should be de-listed, in some cases automatically ([scanner integration] Automatically delist instances with landing pages served with non-200 HTTP status #493, [scanner integration] Automatically delist instances with major landing page HTTPS issues #492, [scanner integration] Automatically delist instances with extended downtime #504)
• if an issue is moderate or serious and can be counteracted through use of Tor, we show a moderate or severe warning
• [scanner integration] Show severe warning on directory entry page for entries with third party assets/analytics scripts #496 and [scanner integration] Show moderate warning on directory entry page for landing pages hosted on subdomain #497 capture all issues that we can detect now or in the near future that warrant a moderate or severe warning

A primary candidate for consideration in the "moderate" warning category would be the failure to set a reasonable referrer policy. However, we should go through the landing page issues we can detect systematically and decide if any should be elevated to the "moderate" or "severe" category.

[eloquence]

Capturing my notes from discussion with @emkll today. @emkll - please review; if this recap looks good to you and @redshiftzero , we can close this issue.

Security context

It's important to note that all SecureDrop directory pages display a prominent banner encouraging the use of the Tor browser. Clearnet access to SecureDrop.org and the browsing of landing pages in a clearnet browser pose inherent risks to sources that cannot be trivially mitigated against except through use of Tor.

For example, while a landing page might follow our recommendations on caching headers, this does nothing to eliminate forensic evidence in browser histories.

The landing page scanner allows us to detect issues that can be remedied, but without a direct working relationship with the operators of a SecureDrop instance, there may be more severe security issues unknown to us. Operational security failures in the handling of USB drives, passphrases, and access to the servers are among the most likely security risks.

Visitors of landing pages may be passively monitored (e.g., via third party assets embedded in landing pages). They may also be actively targeted (e.g., via malicious scripts and phishing attacks).

While we can recommend mitigative actions that site operators can take against active attacks, the security characteristics of the web server the landing page is hosted on are ultimately unknown to us, and we cannot make credible statements about the true risk to the user that a landing page has been compromised.

Incentives and transparency

When it comes to the security properties of landing pages, we can incentivize good behavior or penalize bad behavior. We can inform end users actively about risks or privately reach out to news organizations operating SecureDrop.

This integration plan tries to carefully balance these different strategies:

• It penalizes egregious landing page security failures (e.g., HTTPS not enforced on the landing page) by delisting an instance completely.
• It mildly penalizes moderate-to-serious landing page security failures, especially those that significantly increase the risk of passive monitoring, and actively warns users to take mitigative steps.
• It provides baseline information for outreach news organizations for less significant landing page security failures. In future, we may use verification as a positive incentive (Introduce "Verified" badge in SecureDrop directory #511).

Landing page issues we can detect with the current scanner are summarized in Appendix B of the original scanner integration proposal. We also require the ability to detect third party cookies (#495), the Referrer-Policy header (#515) and direct .onion links (#508) prior to launch.

Reasons why we consider these issues worthy of a user warning are identified in the respective issues.

Issues warranting outreach, but no user-visible warning

The following issues will be recorded and used as part of outreach to news organizations. In future, all or some of them will likely be part of the security standard required for earning a "Verified" badge.

• X-Frame-Options: Useful protection, but does not impact users who visit the landing page through SecureDrop.org.
• First party cookies, caching headers: Forensic evidence. It's useful to prevent such data accumulation about landing page usage, but not sufficient by itself (cf. browser history).
• Cloudflare/Cloudfront-style CDN: Moderate risk of subpoena against and surveillance of a third party. However, CDNs provide useful security protections, and are extremely widespread. Not realistically actionable for many operators of SecureDrop instances.
• HSTS and other HTTPS improvements: provide useful security properties, but we always link to the landing page in HTTPS, so it does not impact users who visit via securedrop.org.
• CSP, X-XSS-Protection, X-Content-Type-Options: nosniff: provide useful security properties, but by themselves are only risk mitigation that require other security failures to exploit.
• X-Download-Options: IE8-specific (very low impact setting, long term inclusion in header recommendations is debatable)
• X-Permitted-Cross-Domain-Policies: Flash and PDF-specific (very low impact setting, long term inclusion in header recommendations is debatable)

[emkll]

Thanks for updating the ticket @eloquence, this looks good to me. With the updated requirements in the proposal, I think we have a good rationale for the scoring, which are at a high level:

1. De-list if HTTPS isn't enforced
2. Severe warning for issues where a prospective source can be identified by an external third party through third-party resources running in the browser.
3. Moderate warning where an adversary in a privileged network position can identify a prospective source.
4. Verified badge when an org does the above and enables all security headers.

[eloquence]

That's a very nice concise summary - thanks, @emkll. We might roll other stuff beyond headers into "Verified", but that's TBD down the road. :)

[redshiftzero]

Thank you for the rigorous enumeration here @eloquence & @emkll ❤️. One thought: in the same category as DNS requests to .onion addresses are direct links to securedrop.org. While this obviously doesn't help sources that find SecureDrop through the SecureDrop website, it can help in the (hopefully more common) situation where sources find SecureDrop via the news organization's tips/landing page, where discouraging direct links back to the SecureDrop.org website may prevent them from being trivially identified. Otherwise I am on board 100% with this plan.

[eloquence]

Thanks, @redshiftzero ! I agree that links to securedrop.org are problematic and we should scan for them (we are tracking this as #507). I'm doubtful that we should warn about it on the directory entry pages (because warnings seem most useful to me when they're directly relevant to what the user is currently doing, and they are on securedrop.org), but it seems like the kind of issue that should be rolled into verification at a minimum.

[conorsch]

direct links to securedrop.org

We don't (yet) offer an Onion URL for SecureDrop docs, but once we have that, it'll accommodate. Can immediately spin-up a unique THS for the docs—integrating inside the existing http://secrdrop5wyphb5x.onion would take more work.

[eloquence]

A separate docs THS would be excellent as a starting point. We do recommend pointing to the existing .onion service in https://docs.securedrop.org/en/stable/deployment/landing_page.html#avoid-direct-links-to-securedrop-org and can also emphasize a docs service address there, once it exists.

[conorsch]

Sure, my sole concern with a separate THS is future compatibility, but we can handle that separately, e.g. via redirects or otherwise. Happy to handle.