In response to NSA’s XKeyscore, Wikimedia to enable HTTPS by default starting with logged-in users on August 21

The Wikimedia Foundation today announced its response to yesterday’s leaks regarding the NSA’s XKeyscore program: turning on HTTPS by default for all Wikimedia projects. The organization is starting by flipping the https switch for all logged-in users on August 21.

Wikimedia says it has been planning to make the move for a while now; it was “considered for this year’s official roadmap” and has been on the unofficial roadmap since native HTTPS was enabled in October 2011.

“Since we appear to be specifically targeted by XKeyscore, we’ll be speeding up these efforts,” the foundation said. Unfortunately, since Wikimedia’s current architecture cannot handle HTTPS by default, the process will take many incremental steps.

As such, Wikimedia has shared its internal roadmap for rolling out https by default, broken down 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.

As you can see, Wikimedia hasn’t shared specific dates beyond August. We’ll keep you posted as plans move forward.

See also – Wikimedia rolls out WYSIWYG visual editor for logged-in users accessing Wikipedia articles in English and Wikipedia Zero arrives in India, dropping mobile data charges for 60m Aircel subscribers