FORCE_SSL constant for really forcing SSL

johnbillion - any movement here? We're (too) late for 4.0.

28521.diff​ gets this started/is woefully inadequate

See #15928 for discussion of pitfalls.

Any progress on this? It's really frustrating to do a fresh install of WordPress 4.4.2 and still see mixed content problems on the setup-config.php and install.php pages, not to mention all the other problems post-install.

This should be considered more major on this current scenario as browsers like Chrome will mark all HTTP sites as 'not secure' starting in July, 2018.

Has anyone talked about starting a feature plugin for working on implementation? I'm keen to collaborate on this.

#27954 was marked as a duplicate.

I've created a feature plugin repo for collaborating on this: ​https://github.com/xwp/pwa-wp

Though I realize that HTTPS may need lower-level core modifications than can be achieved than using a plugin.

HTTPS-labeled issues in feature plugin: ​https://github.com/xwp/pwa-wp/issues?q=label%3Ahttps

Pull request for detecting HTTPS support, essentially eliminating the need to opt-in to HTTPS via a constnat: ​https://github.com/xwp/pwa-wp/pull/16

PWA feature plugin is now live on WordPress.org: ​https://wordpress.org/plugins/pwa/

As ​posted in Slack (in the newly-secured ​#core-https channel), I did a quick reflection on what would make sense as part of 4.9.9:

1. Detect whether HTTPS is available (by doing loopback request).
2. Default to setting home and siteurl to HTTPS when installing WordPress (if HTTPS is available).
3. If HTTPS is not enabled, show a warning notice about why it is important. Include link to Codex page.

Stretch goals for 4.9.9:

4. Add checkbox under Home and Site URL fields to opt user into HTTPS (even when WP_HOME and WP_SITEURL constants are set); doing so would force HTTPS via filters on home and siteurl options, respectively.
5. Scrape content of homepage to see if there are any external HTTP resources which would fail if switched to HTTPS, and show warning.
6. Add redirect from HTTP to HTTPS for requests that don't already do this via redirect_canonical().
7. Add Content-Security-Policy: upgrade-insecure-requests response header if HTTPS is enabled. This is supported in all browsers other than IE11 and avoids the need to do messy s/http/https/ string replacements in the_content, enqueued scripts/styles, etc.
8. Add HSTS response header.

Thoughts? Anything else I'm forgetting?

Replying to westonruter:

8. Add HSTS response header.

Is that safe to do by default? It seems like most users won't be aware of the consequences, or understand them.

If they ever lose their SSL (by switching to a host that doesn't have Let's Encrypt, deciding they don't want to pay for their host's SSL upgrade anymore, experience technical difficulties renewing, etc), then instead of the site (somewhat) gracefully downgrading to HTTP, return browsers would continue redirecting to HTTPS for the remainder of the max-age, and then throw up a big scary warning that the site isn't safe.

It seems like it may be something that's best left to experienced users to intentionally configure after they've understood the requirements and committed to the process. See the attachment below for the warning that CloudFlare shows to users when they start to configure HSTS.

Such functionality should not enable an HSTS header without an explicit request to do so. See the What we won't do section in the ticket description.

Replying to iandunn:

It seems like it may be something that's best left to experienced users to intentionally configure after they've understood the requirements and committed to the process. See the attachment below for the warning that CloudFlare shows to users when they start to configure HSTS.

Agreed.

cf. ​https://github.com/xwp/pwa-wp/pull/82#issuecomment-426152696

#38148 was marked as a duplicate.

This ticket was raised again at contributor day at WCEU 2023 and still seems relevant. I think this could go forward without the HSTS part and will work on a patch.

#38259 was marked as a duplicate.

#38260 was marked as a duplicate.

#38261 was marked as a duplicate.

#38262 was marked as a duplicate.