[Spike] Remove pshtt to see what breaks

[sssoleileraaa]

Description

Before we update https://github.com/freedomofpress/pshtt to use the latest sslyze package (we're currently on 3.0.0, and you can see that there have been quite a few changes since then: https://github.com/nabla-c0d3/sslyze/compare/3.0.0..5.1.2), let's evaluate whether or not we want to continue maintaining https://github.com/freedomofpress/pshtt. Here are some open questions to get us started:

• Is pshtt only used for the Scan Results page/ landing page alerts feature?
• How do we use this feature in practice?
• Should we reconsider moving back to the original repo instead of maintaining our own fork and then just making PRs to update dependencies?
• Are there alternative tools that are better maintained?
• Any other considerations?

Background

We maintain a fork of pshtt (for background as to why and when, see https://github.com/freedomofpress/fpf-www-projects/issues/150). Four days ago, sslyze 5.1.2 was released with dependency upgrades, which included an upgrade to cryptography (see https://github.com/nabla-c0d3/sslyze/releases/latest). This means we can update our fork, which will subsequently mitigate the cryptography alerts that we've been ignoring (note: the web team determined that it was safe to ignore these since we only use pshtt to scan 3rd party sites). @harrislapiroff - please chime in if I missed any relevant background information that might be helpful.

[eloquence]

I chatted a bit with @nathandyer about this. He confirmed that he's not relying on https://securedrop.org/admin/directory/scanresult/create/ (manual per-URL scans) or https://securedrop.org/admin/directory/scanresult/ (all scan results) in his directory audits; he does landing page checks manually with command-line tooling and browser dev tools.

The per-URL scanner appears to be broken right now, in any event - it produces a 500 error for any URL I've tried.

I think there's a good argument to be made to dramatically simplify our scan logic to only scan for things we actually throw up warnings for, which probably does not require use of pshtt. If we do need to expand our checks from there, we can always write our own code on an as-needed basis, rather than just recording everything we get from pshtt in the assumption we might need it some day.

[harrislapiroff]

Updated this issue title to "Remove pshtt," in light of @eloquence's research. We can implement our own functions for scanning the things we alert for.