WordPress.org

Make WordPress Core

Opened 5 years ago

Last modified 2 weeks ago

#28521 new enhancement

FORCE_SSL constant for really forcing SSL

Reported by: johnbillion Owned by:
Milestone: Future Release Priority: normal
Severity: normal Version:
Component: Security Keywords: needs-patch https
Focuses: Cc:

Description

Previously: #27954.

As per this post on make/core and its comments, we should introduce a new constant which becomes the iron-fisted ruler of HTTPS, imposing its might everywhere it can.

If this constant is set, we will:

  • Force https connections (pretty much covered by #27954)
  • Force local URLs within content to https
  • Force local enqueued scripts and styles to https
  • Force non-local enqueued scripts and styles to https
  • Set the secure flag on all cookies

What we won't do:

  • Force non-local URLs within content to https
  • Force the https version of oEmbeds just yet - see #28507
  • Send an HSTS header - see #28520

What I'm not sure on:

  • Should we force https connections for XML-RPC? See #28424.

Attachments (2)

28521.diff (5.5 KB) - added by wonderboymusic 4 years ago.
cloudflare-hsts-warning.png (448.4 KB) - added by iandunn 2 weeks ago.

Download all attachments as: .zip

Change History (25)

This ticket was mentioned in IRC in #wordpress-dev by DrewAPicture. View the logs.


5 years ago

#2 @helen
5 years ago

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

#3 @johnbillion
5 years ago

  • Milestone changed from 4.0 to Future Release

@wonderboymusic
4 years ago

#4 @wonderboymusic
4 years ago

  • Keywords needs-patch added

28521.diff gets this started/is woefully inadequate

#5 @boonebgorges
4 years ago

See #15928 for discussion of pitfalls.

This ticket was mentioned in Slack in #core by johnbillion. View the logs.


4 years ago

#7 @johnbillion
3 years ago

  • Keywords https added

This ticket was mentioned in Slack in #core by johnbillion. View the logs.


3 years ago

#9 @pcgeek86
3 years ago

  • Keywords changed from needs-patch, https to needs-patch https

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.

#10 @josevarghese
15 months ago

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.

Last edited 15 months ago by josevarghese (previous) (diff)

#11 @westonruter
14 months ago

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

#12 @westonruter
12 months ago

#27954 was marked as a duplicate.

#13 @westonruter
12 months ago

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.

Last edited 12 months ago by westonruter (previous) (diff)

#14 @westonruter
11 months ago

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

#15 @westonruter
11 months ago

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

This ticket was mentioned in Slack in #core by westonruter. View the logs.


9 months ago

This ticket was mentioned in Slack in #core by westonruter. View the logs.


8 months ago

#18 follow-up: @westonruter
8 months ago

  • Milestone changed from Future Release to 4.9.9

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:

  1. 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.
  2. Scrape content of homepage to see if there are any external HTTP resources which would fail if switched to HTTPS, and show warning.
  3. Add redirect from HTTP to HTTPS for requests that don't already do this via redirect_canonical().
  4. 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.
  5. Add HSTS response header.

Thoughts? Anything else I'm forgetting?

Last edited 2 weeks ago by westonruter (previous) (diff)

This ticket was mentioned in Slack in #core-https by westonruter. View the logs.


8 months ago

#20 @pento
8 months ago

  • Milestone changed from 4.9.9 to Future Release
  • Type changed from task (blessed) to enhancement

#21 in reply to: ↑ 18 ; follow-up: @iandunn
2 weeks ago

Replying to westonruter:

  1. 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.

#22 @johnbillion
2 weeks ago

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.

#23 in reply to: ↑ 21 @westonruter
2 weeks ago

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

Note: See TracTickets for help on using tickets.