Opened 10 years ago
Last modified 18 months ago
#28521 assigned enhancement
FORCE_SSL constant for really forcing SSL
Reported by: | johnbillion | Owned by: | 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)
Change History (28)
This ticket was mentioned in IRC in #wordpress-dev by DrewAPicture. View the logs.
10 years ago
This ticket was mentioned in Slack in #core by johnbillion. View the logs.
9 years ago
This ticket was mentioned in Slack in #core by johnbillion. View the logs.
9 years ago
#9
@
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
@
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.
#11
@
7 years ago
Has anyone talked about starting a feature plugin for working on implementation? I'm keen to collaborate on this.
#13
@
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.
#14
@
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
@
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:
↓ 21
@
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:
- Detect whether HTTPS is available (by doing loopback request).
- Default to setting
home
andsiteurl
to HTTPS when installing WordPress (if HTTPS is available). - 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:
- Add checkbox under Home and Site URL fields to opt user into HTTPS (even when
WP_HOME
andWP_SITEURL
constants are set); doing so would force HTTPS via filters onhome
andsiteurl
options, respectively. - Scrape content of homepage to see if there are any external HTTP resources which would fail if switched to HTTPS, and show warning.
- Add redirect from HTTP to HTTPS for requests that don't already do this via
redirect_canonical()
. - 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 inthe_content
, enqueued scripts/styles, etc. Add HSTS response header.
Thoughts? Anything else I'm forgetting?
This ticket was mentioned in Slack in #core-https by westonruter. View the logs.
6 years ago
#20
@
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:
↓ 23
@
6 years ago
Replying to westonruter:
- 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
@
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
@
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
johnbillion - any movement here? We're (too) late for 4.0.