Update status does not verify the identity or authenticity of the release history URL

Problem/Motivation

If the video filter man in the middle XSS (eg via evil DNS) is classified as a security issue, shouldn’t the current update status process (eg via admin/reports/updates/update) be marked a security issue as well?

As far as I can see there are no authenticity checks whatsoever on the release data and download.

This can be used to

1 - prevent reception of update alerts via the update status channel
2 - entice admins to install modules from untrusted servers

(this has been cleared by the secteam for public discussion, the suggestion was the Infra queue, but it would need Core support as well).

Steps to reproduce

Enable Update manager

Proposed resolution

• Try to fetch over https.
• Print warning messages on the available updates report and the 'Update' form if the site failed to fetch data, warning admins about proper HTTPS config
• Fallback to the current HTTP URL only if the 'update_fetch_with_http_fallback' setting has been overridden to TRUE (defaults FALSE).
• Migration to D8/9 sites from D7 and before will re-write the update_fetch_url config from HTTP to HTTPS

E-mailing admins if their site is failing to fetch info is at #3162336: Update manager should email admins when it fails to fetch available update data

Remaining tasks

1. Create the d.o handbook page documenting the details so we can link to it. Update the @todo URL in the patch.https://www.drupal.org/docs/system-requirements/php-openssl-requirements (see patch #137)
2. Decide if we need the flexibility of a Twig template for this (#132) or if we can just use some hard-coded stuff via the Messenger service (#134).
3. Decide if we need DI for the UpdateManagerUpdate form (#135a) or can just use \Drupal::service() (#135b)
4. Decide what (if any) new automated testing we need for the error messages, fallback setting, etc.
5. Needs manual testing
6. Needs UX review See #136
7. Maybe needs a product manager review?
8. Needs a release manager review to decide about backports with all these new strings and other changes
9. Release note snippet?
10. CR?
11. RTBC
12. Commit
13. Backport(s)?

User interface changes

New messages if Update Manager fails to fetch available updates (presumably because the site's PHP isn't configured for outbound HTTPS requests to work):

Available updates report

Update form

Cryptic watchdog message

This is why we need a handbook page. ;)

New setting documented in default.settings.php

/**
 * Fallback to HTTP for Update Manager.
 *
 * If your Drupal site fails to connect to updates.drupal.org using HTTPS to
 * fetch Drupal core, module and theme update status, you may uncomment this
 * setting and set it to TRUE to allow an insecure fallback to HTTP. Note that
 * doing so will open your site up to a potential man-in-the-middle attack. You
 * should instead attempt to resolve the issues before enabling this option.
 * @see https://www.drupal.org/docs/system-requirements/php-requirements#openssl
 * @see https://en.wikipedia.org/wiki/Man-in-the-middle_attack
 * @see \Drupal\update\UpdateFetcher
 */
# $settings['update_fetch_with_http_fallback'] = FALSE;

API changes

• New public \Drupal\update\UpdateManager::getFetchErrorMessage() method.
• New protected \Drupal\update\UpdateFetcher::doRequest() method.
• \Drupal\update\UpdateFetcher (the 'update.fetcher' service) now needs the 'renderer' service injected.
• TBD: UpdateManager service injected into \Drupal\update\Form\UpdateManagerUpdate?

Data model changes

N/A

Release notes snippet

The Update Manager how fetches available update data over HTTPS. Your site's PHP must have OpenSSL properly configured. If that's not possible, you can set $settings['update_fetch_with_http_fallback'] = TRUE; in your settings.php file to use the less secure HTTP fallback. See the PHP OpenSSL requirements section of the Drupal.org handbook for more details.