WordPress.org

Make WordPress Core

Opened 4 weeks ago

Last modified 3 weeks ago

#47577 new enhancement

Streamline detecting and enabling HTTPS

Reported by: flixos90 Owned by:
Milestone: Awaiting Review Priority: normal
Severity: normal Version:
Component: Administration Keywords: 2nd-opinion needs-unit-tests has-patch
Focuses: Cc:

Description

Of all the WordPress sites today, 63.4% are using HTTPS. While this is already better than the average for the entire web, it is far from optimal. More and more modern web APIs require usage of HTTPS, let alone the security implications of not using it.
In order to close that gap, it must be easier for administrators to switch their WordPress site to HTTPS, especially if it is already supported by their environment.

In order to provide accurate recommendations to site owners about switching their site to HTTPS, we need to know whether HTTPS is even supported by their server and domain. We have been reliably detecting HTTPS support in the PWA plugin for a while, and the same logic could be used in core.

Based on the result of the HTTPS support detection, we would recommend one of the following:

  • If supported, recommend to change the WordPress site URL, as that's all that's needed.
  • If not supported, recommend talking to the web host about enabling HTTPS.

This provide more accurate recommendations for the respective situation a site is in.

In order to properly enable HTTPS it is also crucial to not have mixed content links. Performing extensive database replacements is unfeasible for WordPress core itself, so we should instead replace URLs in content pointing to http:// versions of the page with their https:// counterparts on the fly. While this would be unnecessary for sites that properly have switched all their content to HTTPS, the overhead is minimal and acceptable. Last but not least, if somebody still doesn't want it, those checks should be removable easily because of the filter usage.

Attachments (3)

47577.diff (7.6 KB) - added by flixos90 4 weeks ago.
Screenshot 2019-06-20 at 13.47.12.png (65.5 KB) - added by flixos90 4 weeks ago.
Screenshot of when HTTPS is not enabled, but supported by the environment
Screenshot 2019-06-20 at 13.55.15.png (58.1 KB) - added by flixos90 4 weeks ago.
Screenshot of when HTTPS is not enabled and also not supported by the environment

Download all attachments as: .zip

Change History (9)

@flixos90
4 weeks ago

#1 follow-up: @flixos90
4 weeks ago

  • Keywords has-patch added; needs-patch removed

47577.diff makes the following changes:

  • Introduce wp_is_using_https(), which detects whether the site uses HTTPS based on the WordPress site URL.
  • Introduce wp_is_https_supported() which detects whether HTTPS is supported by the environment (using a cached request to the HTTPS version of the site).
  • Enhance the Site Health test for HTTPS status to use the new function and provide accurate recommendation based on the results.
  • If HTTPS is active, filter and replace non-HTTP links to the site in content with their HTTPS counterparts.

@flixos90
4 weeks ago

Screenshot of when HTTPS is not enabled, but supported by the environment

@flixos90
4 weeks ago

Screenshot of when HTTPS is not enabled and also not supported by the environment

#2 @earnjam
4 weeks ago

It would be nice to allow filtering the Site Health action link/button for talking to your host about HTTPS in the same way we do for the PHP upgrade notices.

Hosts will have differing documentation about how to accomplish it on their environments and they may want to link directly to that.

#3 @johnbillion
4 weeks ago

Related: #28521 (for considerations related to filtering URL schemes).

#4 in reply to: ↑ 1 @westonruter
4 weeks ago

Replying to flixos90:

  • If HTTPS is active, filter and replace non-HTTP links to the site in content with their HTTPS counterparts.

I suggest also adding a upgrade-insecure-requests CSP directive to automatically handle this outside fo the content: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy/upgrade-insecure-requests

#5 follow-up: @flixos90
3 weeks ago

@earnjam

It would be nice to allow filtering the Site Health action link/button for talking to your host about HTTPS in the same way we do for the PHP upgrade notices.

I like that suggestion, however I'd prefer if we approached this iteratively and opened a follow-up issue to make that URL filterable. The complexity we've learned about during the Servehappy project is that we probably wouldn't want them to replace the wordpress.org support URL, so we'd need to add more content and tweak the UI to allow for that, which would require more discussion.

@westonruter

I suggest also adding a upgrade-insecure-requests CSP directive to automatically handle this outside fo the content

That's worth exploring. I'm wondering whether that would cause problems with URLs pointing to external websites, that may still not be on HTTPS though - how does the directive deal with images or links from such websites? The other concern is that in order to add CSP headers into core, it may be better to work on a simple centralized solution as a developer API that would allow managing those directives.

#6 in reply to: ↑ 5 @westonruter
3 weeks ago

Replying to flixos90:

I suggest also adding a upgrade-insecure-requests CSP directive to automatically handle this outside fo the content

That's worth exploring. I'm wondering whether that would cause problems with URLs pointing to external websites, that may still not be on HTTPS though - how does the directive deal with images or links from such websites? The other concern is that in order to add CSP headers into core, it may be better to work on a simple centralized solution as a developer API that would allow managing those directives.

Hyperlinks to other websites would be ignored since merely linking to another site does not cause a request. Images, videos, iframes, and other resources would need to be upgraded even on external domains as otherwise there would be insecure mixed content warnings.

Per MDN:

The upgrade-insecure-requests directive will not ensure that users visiting your site via links on third-party sites will be upgraded to HTTPS for the top-level navigation

Note: See TracTickets for help on using tickets.