Wikimedia Plans To Beef Up Security Across Projects With HTTPS
The Wikimedia Foundation is working on making its projects more secure to protect users’ privacy.
As one can imagine, there are plenty of technological obstacles that the foundation must overcome, so it’s going through the process a little at a time. The foundation has outlined its current roadmap in a blog post.
“The Wikimedia Foundation believes strongly in protecting the privacy of its readers and editors,” writes Wikimedia Foundation operations engineer Ryan Lane. “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.”
“Our current architecture cannot handle HTTPS by default, but we’ve been incrementally making changes to make it possible. Since we appear to be specifically targeted by XKeyscore, we’ll be speeding up these efforts,” adds Lane.
First on the agenda is redirecting to HTTPS for log-in, and keeping logged-in users on HTTPS. The foundation intends to deploy this on August 21st.
Next, the foundation intends to expand the HTTPS infrastructure, moving the SSL terminators directly onto the frontend varnish caches and expanding the frontend caching clusters. Then, it will look to “more properly” distribute its SS load across the frontend caches.
Wikimedia will then slowly soft-enable HTTPS for anonymous users by default, starting with its smaller projects. It will do so by changing its rel=canonical links to point to the HTTPS version of pages, rather than the HTTP versions, which will cause search engines to return HTTPS results.
After that, the foundation will then consider enabling “perfect forward secrecy,” hard-enabling HTTPS (force redirecting users to HTTPS versions), and enabling HTTP Strict Transport Security to protect against SSL-stripping attacks.
Wikimedia doesn’t have eexact time frames associated with any of the changes other than the aforementioned August date for redirecting logged-in users.