Display notice if HTTPS is not enabled, use 301 code in redirect

[kienstra]

As a follow-up to #17:

• Display a notice if the siteurl and home (WordPress Address and Site Address) are HTTP, and HTTPS is not enabled (like if there's no certificate)

• Change the code in the redirect from 302 to 301:

https://github.com/xwp/pwa-wp/blob/e1431eae92f75a09742c7cdd3dc438011f53fb9d/wp-includes/class-wp-https-ui.php#L358

[igrigorik]

Strong 👍 to both.

(a) What will be the messaging for no HTTPS?

(b) FWIW, there is a use case for 302, but we wouldn't want that to be the permanent setting. A 302 is useful and relevant when you're testing a site migration: you want to see it live, but you may not be ready to signal to all the crawlers that HTTPS is the new "canonical". However, to complete the migration we definitely need the 301 as the final destination. Ideally, there would be some "burn in" period where 302 is used to verify and troubleshoot, with a 301 switch once everything is confirmed.

[westonruter]

This burn-in period sounds similar to what we were thinking of for HSTS. Maybe adding HSTS could be the final step in the burn-in period, with exponential backoff of the TTL. So maybe:

• 1 week of 302 redirects, followed by 301
• then 1 week of HSTS at 60 minute TTL,
• then 1 month of HSTS at 24 hour TTL
• then permanently setting HSTS to an optimal TTL (e.g. 1 month or longer)

[kienstra]

Redirect Code, HTTPS Notice

Hi @westonruter and @igrigorik,
(a) Good ideas for phasing in a 301 redirect code.

(b) Here's some possible copy for an admin notice if HTTPS is not possible, like if there's no certificate:

HTTPS is not enabled on your site, possibly because there's no SSL certificate, or an invalid one. We strongly suggest enabling it for better security. More details

[igrigorik]

Re, HTTPS notice, some suggestions..

HTTPS is not enabled on your site, possibly because there's no TLS certificate, or it is invalid. We strongly suggest enabling it for better security. More details

For the "more details" link, are there any other pages that we could link to in the codex, that focus on the user+site owner benefits of HTTPS instead of the technical guidance? I don't think that page does a good job of motivating the claim we're proposing in the notice.

If there aren't resources in the codex, could we link to: https://developers.google.com/web/fundamentals/security/encrypt-in-transit/why-https ?

---

Re, burn-in period: @westonruter how do you see the proposed schedule working?

• If I enable the setting, does the plugin automatically setup a 302 and later "upgrades it" to 301 without further user action?
• What would happen if I come in and toggle the setting on and off, would that reset the schedule?

[kienstra]

Link For 'More details'

Hi @igrigorik,

For the "more details" link, are there any other pages that we could link to in the codex, that focus on the user+site owner benefits of HTTPS instead of the technical guidance? I don't think that page does a good job of motivating the claim we're proposing in the notice.

Good question. I couldn't find a page on wordpress.org that better describes the benefits of HTTPS.

[igrigorik]

@kienstra @westonruter could we link to the Web Fundamentals article then? Are there any best practices / requirements on links from WP dashboard?

[kienstra]

Hi @igrigorik,

Sure, I think it'd be fine to link to the Web Fundamentals article.

Are there any best practices / requirements on links from WP dashboard?

Good question. I couldn't find any documentation or best practices on links in the dashboard.

But it looks like all of 5 of the external links on 'Settings' pages are to the Codex (in 'General Settings,' 'Writing Settings,' and 'Permalink Settings').

[igrigorik]

I suspected as much. If there are no objections, let's go with the WF link. If there is push back down the road, we can investigate other options. I just don't feel that the current codex page on HTTPS covers the motivation sufficiently well.

[westonruter]

@igrigorik:

Re, burn-in period: @westonruter how do you see the proposed schedule working?

• If I enable the setting, does the plugin automatically setup a 302 and later "upgrades it" to 301 without further user action?

Yes, that's right.

• What would happen if I come in and toggle the setting on and off, would that reset the schedule?

That sounds like a good idea.

could we link to the Web Fundamentals article then? Are there any best practices / requirements on links from WP dashboard?

For core merge proposal we would definitely need a WordPress Codex page for HTTPS. In the mean time, linking to WF is fine.

Here are all of the linked URLs that I can find in the admin: https://gist.github.com/westonruter/01d87482846aa8131afca186cad2de0f

There are only 3 exceptions to linking to WordPress.org URLs:

• http://gmpg.org/xfn/
• https://www.fsf.org/
• https://gravatar.com

[igrigorik]

What would happen if I come in and toggle the setting on and off, would that reset the schedule?
That sounds like a good idea.

Hmm, there is a complication here. Once you set 301 and/or HSTS, and you uncheck the setting.. The users may still be directed to HTTPS (due to HSTS policy), and you'd need a 301 from the HTTPS back to HTTP for crawlers if you want to avoid any confusion there.

302 is safe "testing mode". Once you flip the 301 + HSTS switch though, going back is much harder. I think it's worth spending a bit more time on the UX here: how we communicate the 302 / testing, if/how the transition to 301 happens, and what happens when you try to "revert" the 301.

For core merge proposal we would definitely need a WordPress Codex page for HTTPS. In the mean time, linking to WF is fine.

What's the process for updating codex pages? If we can update the HTTPS page to cover the why, perhaps even by linking to WF, then I'm a happy camper.

[westonruter]

What's the process for updating codex pages? If we can update the HTTPS page to cover the why, perhaps even by linking to WF, then I'm a happy camper.

I've raised the topic in WordPress core dev chat today: https://wordpress.slack.com/archives/C02RQBWTW/p1536178915000100

I was really happy with the positive response. It was proposed that the HTTPS detection and switchover could be incorporated into a new “Site Health Check” initiative which would be merged into core, and the WordPress marketing team would include HTTPS in the materials that are presented to users to explain the importance of securing their sites.

[igrigorik]

That's awesome! What's the best way to track that discussion and is there an ETA or deadline for this?

[westonruter]

@igrigorik Probably by joining the #core-http Slack channel: https://wordpress.slack.com/messages/C0AHSFXSA

Also, as @schlessera noted:

The alert that the site is not on HTTPS could be part of the "Site Health Check" we're working on (pivot on ServeHappy).

The discussion conversation about HTTPS should probably be tracked as part of Site Health Check discussions: https://make.wordpress.org/core/?s=%22Site+Health+Check%22

This post has a roadmap: https://make.wordpress.org/core/2018/07/17/servehappy-roadmap-update-and-priorities/

It is currently envisioned to have the first iteration ship as part of WordPress 5.0, however depending on when that version is released, this may change. It is certainly no hard deadline in that regard.

/cc @felixarntz

[igrigorik]

Cool, thanks for the details. I'll defer to you guys to drive this. LMK if there is anything I can help with :)