Make WordPress Core

Opened 10 years ago

Last modified 18 months ago

#28521 assigned enhancement

FORCE_SSL constant for really forcing SSL

Reported by: johnbillion's profile johnbillion Owned by: adamsilverstein's profile adamsilverstein
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 10 years ago.
cloudflare-hsts-warning.png (448.4 KB) - added by iandunn 6 years ago.

Download all attachments as: .zip

Change History (28)

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


10 years ago

#2 @helen
10 years ago

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

#3 @johnbillion
10 years ago

  • Milestone changed from 4.0 to Future Release

#4 @wonderboymusic
10 years ago

  • Keywords needs-patch added

28521.diff gets this started/is woefully inadequate

#5 @boonebgorges
10 years ago

See #15928 for discussion of pitfalls.

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


9 years ago

#7 @johnbillion
9 years ago

  • Keywords https added

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


9 years ago

#9 @pcgeek86
9 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
7 years 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 7 years ago by josevarghese (previous) (diff)

#11 @westonruter
7 years ago

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

#12 @westonruter
6 years ago

#27954 was marked as a duplicate.

#13 @westonruter
6 years 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 6 years ago by westonruter (previous) (diff)

#14 @westonruter
6 years 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
6 years 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.


6 years ago

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


6 years ago

#18 follow-up: @westonruter
6 years 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 6 years ago by westonruter (previous) (diff)

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


6 years ago

#20 @pento
6 years 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
6 years 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
6 years 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
6 years 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

#24 @pento
5 years ago

#38148 was marked as a duplicate.

#25 @adamsilverstein
18 months ago

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.

#26 @adamsilverstein
18 months ago

  • Owner set to adamsilverstein
  • Status changed from new to assigned
Note: See TracTickets for help on using tickets.