Reminder: HTTPS meeting tomorrow

The weekly meetings about HTTPS improvements in core will resume tomorrow at 16:00 UTC (Friday, September 30, 2016, 16:00 UTC) in the #core-http channel on Slack. See you there!

#https

HTTPS Working Group

In WordPress 4.4 and 4.5, various pieces of work were done to improve HTTPS support in core, but not much has been tackled since then. To address this, I’m going to re-start the weekly chats in the #core-http channel in Slack. Fridays late afternoon UTC/GMT are good for me — does this work for other people who are interested in helping with HTTPS issues?

Although the HTTPS improvements are always ongoing and not tied to a particular release, it would be great to get some improvements into 4.7.

If you run a WordPress site over HTTPS only, support is very good and there are very few issues to contend with. If you’re running a multisite network on HTTPS there are a few small issues when adding new sites. However, the main HTTPS issues in core come from:

  • Enforcing the HTTPS scheme on assets (such as embedded images in post content, and enqueued JS and CSS).
  • Enforcing the HTTPS scheme on links, redirects, and canonical URLs.
  • Migrating an existing HTTP site to HTTPS.
  • Running a site that uses a mixture of HTTP and HTTPS.

The first two points — avoiding mixed content on HTTPS sites — need to be solved via an opt-in system (either via constants or filters) because enforcing these can cause issues with sites that run proxies (for example Cloudflare’s Universal SSL). Overall though, this ought to be a fairly straight forward set of enhancements to implement.

The third point is a potentially complex one which will need a lot of discussion and some ideas putting forward. How can core make life easier for a site owner who wishes to switch their site from HTTP to HTTPS? Should it be a case of being able to change the scheme in the URL on the General Settings screen or is there too much risk of breakage? What else can be done post-migration to aid the site owner, or will the opt-in enhancements for avoiding mixed content be enough?

The last point is one that, going forward, should be generally discouraged, however it needs to continue to be supported for multisite networks that use domain mapping and can’t serve every domain over HTTPS.

There’s an https keyword on Trac which has been applied to tickets that concern HTTPS issues. We’ll start going through this list in next week’s chat.

Here’s a bunch of further considerations that need to be taken into account while working on HTTPS issues:

  • Differing schemes, domains, and ports in the siteurl and home options.
  • Domain mapping
  • force_ssl_admin() usage
  • Self signed certs
  • No public access to admin URLs
  • Different HTTPS domain on front end (!)
  • HTTP site optionally available over HTTPS

Here’s a list of items that should be considered for enforcing over HTTPS:

  • Enqueued JS and CSS.
  • Post content, images, js, CSS, iframes,srcset, oembeds, forms.
  • How about other fields such as term descriptions, user bios, etc.
  • Force https links. Links to the current site.
  • Force https link in nav menus.
  • Force https redirects and/or canonical.
  • Force HSTS. (Probably not.)
  • Force https rest api endpoint.
  • Force https XML RPC.
  • Set https-only on cookies.

Let me know in the comments if you’d like to help out and if Fridays are good for the meeting time!

#https

HTTPS discussion meeting this Wednesday

In recent releases of WordPress there have been various improvements made to support for sites running on HTTPS. While support is currently very good, it’s still too easy to end up with mixed content on a site (HTTP content embedded within an HTTPS page), and especially so when migrating an existing site from HTTP to HTTPS.

There will be a discussion meeting in the #core-http Slack channel on Wednesday, January 27, 2016 at 2000 UTC. This is one hour before the regular weekly meeting in #core. I’d like to discuss three topics:

  1. Implementing an (opt-in) method of forcing a site to use HTTPS.
    • What should this cover? (Embedded content, enqueued scripts/styles, links, redirects)
    • How should it be implemented? (eg. filter/constant/automatic)
  2. Defaulting to HTTPS for new installs when it’s available.
    • Only applies when setting up a site over HTTP and it’s available over HTTPS.
    • Need to communicate clearly to the user what this implies, with option to toggle.
  3. Aiding in switching an existing site from HTTP to HTTPS.
    • Migrating existing embedded content.
    • Should this be a feature plugin?

If you’re interested in helping out with any of the above, or with HTTPS improvements in general, join us on Wednesday.

Further reading: the https tag on Core Trac.

#https, #meeting

Request for feedback: Your HTTPS configurations

An ongoing goal of WordPress is to improve the way it works for sites that use HTTPS, and more specifically sites that run a mixture of schemes (for example, HTTPS in the admin area but HTTP on the front end).

One of the most visible bugs currently is that media in an HTTPS admin area is served over HTTP unless the ‘WordPress Address’ setting (siteurl) also uses HTTPS, which means that the FORCE_SSL_ADMIN constant isn’t a complete drop-in solution to securing your admin area.

Addressing all the possible configurations of HTTPS is difficult, so I’d like to put out a request for anyone who’s using a particularly interesting HTTPS configuration on your site to let us know what your setup is.

Of particular interest would be a site that’s using different domain names for HTTPS and HTTP, different domain names for the admin area and front end, different ports anywhere, self-signed certs for the admin area, HTTPS admin areas with additional access restrictions, multisites with and without domain mapping that use a mixture of HTTPS and HTTP, etc.

If your site has an interesting HTTPS configuration, and of course if it suffers from scheme related bugs as a result, please let us know in the comments below.

#https

WordPress and HTTP/2

HTTP/2 was finalized by the IETF earlier this year. This update to the HTTP protocol is the first major update in 16 years, since HTTP/1.1 was adopted in 1999. HTTP/2 promises faster websites by reducing latency through various innovations. Additionally, all major browser vendors have announced intentions to support HTTP/2 over TLS/SSL only, meaning that HTTP/2 brings with it an era of HTTPS only websites. For a deeper dive into HTTP/2, highly recommend the chapter on HTTP/2 in High Performance Browser Networking.

For the WordPress 4.4 release cycle, Scott Taylor has asked Eric Andrew Lewis and I to investigate what, if anything, WordPress can do to make HTTP/2 integration seamless. We want to get this discussion started with some initial thoughts and an invitation to brainstorm in a dev chat next week.

HTTP/2 has been developed to just work with existing websites, suggesting that there is nothing in particular that we need to do to make WordPress compatible with HTTP/2; however, for all intents and purposes, HTTPS is required for HTTP/2 to work in browsers. One area of focus for making it easier to deploy WordPress with HTTP/2 is to focus on tickets related to TLS/SSL issues. John Blackbourn has graciously compiled a list of tickets that could use attention:

In addition to focusing on these tickets, Eric and I have started working on more documentation for setting up TLS/SSL for WordPress, which will naturally lend itself to guides on HTTP/2 deployments for WordPress.

As for HTTP/2 and WordPress, we fortunately do not need to anything to make it work and existing web apps are already compatible. If we chose to, we can try to optimize WordPress for HTTP/2. These optimizations could manifest as optional theme support for HTTP/2 (i.e., add_theme_support() value) or using a constant to unlock HTTP/2 optimizations. We could add support for critical rendering path CSS that would allow WordPress to use server push to quickly deliver the assets to the browser. Additionally, we could consider building default themes with non-concatenated JS files to optimize delivery for HTTP/2 (we’d still ship the concatenated version for HTTP/1.1 deployments). These are merely early thoughts on what we might be able to do and we are hoping to gather feedback and ideas here and during the dev chat.

For those interested, Eric and I set up a test bed for HTTP/2 and WordPress. We have two sites set up, one with HTTP/1.1 and one with HTTP/2. Currently, they are running the exact same code base (with Twenty Sixteen!) and only differ in the protocol that is used. We intend to experiment with ideas on this setup. The repo is on Github and we plan to make more setup information available soon.

To kick things off, we will have a meeting on September 10 at 20:00 UTC in the #core room on slack.

#agenda, #http2, #https