Wikipedia to roll out HTTPS by default on some time in August

If you think that Edward Snowden’s various acts of whistle-blowing aren’t changing the web in any way, take a look at this. The Wikimedia foundation has announced that it will be making online encyclopedia Wikipedia HTTPS by default from 21 August.

While there has been pressure on the non-profit to make the encrypted version of the site the default one for some time now, Snowden’s revelation that the US’ National Security Agency (NSA) has software capable of tracking every site you visit has pushed it into accelerating the roll out of HTTPS by default.

According to Wikimedia:

Recent leaks of the NSA’s XKeyscore program have prompted our community members to push for the use of HTTPS by default for the Wikimedia projects. Thankfully, this is already a project that was being considered for this year’s official roadmap and it has been on our unofficial roadmap since native HTTPS was enabled.

The foundation says that its current architecture cannot handle HTTPS by default, but that it’s incrementally making changes to make it possible. It adds however that the fact that it’s targeted specifically by the NSA’s XKeyscore program means that it’ll be focusing more resources on those efforts.

Wikimedia has broken down its roadmap for migrating to HTTPS by default into seven points:

1. Redirect to HTTPS for log-in, and keep logged-in users on HTTPS. This change is scheduled to be deployed on August 21, at 16:00 UTC.
2. Expand the HTTPS infrastructure: Move the SSL terminators directly onto the frontend varnish caches, and expand the frontend caching clusters as necessitated by increased load.
3. Put in engineering effort to more properly distribute our SSL load across the frontend caches. In our current architecture, we’re using a source hashing based load balancer to allow for SSL session resumption. We’ll switch to an SSL terminator that supports a distributed SSL cache, or we’ll add one to our current solution. Doing so will allow us to switch to a weighted round-robin load balancer and will result in a more efficient SSL cache.
4. Starting with smaller projects, slowly soft-enable HTTPS for anonymous users by default, gradually moving toward soft-enabling it on the larger projects as well. By soft-enable we mean changing our rel=canonical links in the head section of our pages to point to the HTTPS version of pages, rather than the HTTP versions. This will cause search engines to return HTTPS results, rather than HTTP results.
5. Consider enabling perfect forward secrecy. Enabling perfect forward secrecy is only useful if we also eliminate the threat of traffic analysis of HTTPS, which can be used to detect a user’s browsing activity, even when using HTTPS.
6. Consider doing a hard-enable of HTTPS. By hard-enable we mean force redirecting users from HTTP pages to the HTTPS versions of those pages. A number of countries, China being the largest example, completely block HTTPS to Wikimedia projects, so doing a hard-enable of HTTPS would probably block large numbers of users from accessing our projects at all. Because of this, we feel this action would probably do more harm than good, but we’ll continue to evaluate our options here.
7. Consider enabling HTTP Strict Transport Security (HSTS) to protect against SSL-stripping man-in-the-middle attacks. Implementing HSTS could also lead to our projects being inaccessible for large numbers of users as it forces a browser to use HTTPS. If a country blocks HTTPS, then every user in the country that received an HSTS header would effectively be blocked from the projects.

People logged in to Wikipedia will be the first to get HTTPS by default on 21 August, but Wikimedia hasn’t provided any specific dates for when it will be rolled out to the mass market.