English
The Wikimedia Foundation believes strongly in protecting the privacy of its readers and editors. 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. Here’s our current internal roadmap:
- 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.Update as of 21 August: we have delayed this change and will now deploy it on Wednesday, August 28 at 20:00 UTC/1pm PT. - 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.
- 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.
- 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.
- 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.
- 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.
- 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.
Currently we don’t have time frames associated with any change other than redirecting logged-in users to HTTPS, but we will be making time frames internally and will update this post at that point.
Until HTTPS is enabled by default, we urge privacy-conscious users to use HTTPS Everywhere or Tor [1].
Ryan Lane
Operations Engineer, Wikimedia Foundation
[1]: There are restrictions with Tor; see Wikipedia’s information on this.
中文
关于维基媒体计划中HTTPS协议使用的未来构想
维基媒体基金会非常重视保护读者和编辑者的隐私。最近被曝光的NSA的XKeyscore项目促使着我们要使用HTTPS作为社区会员访问维基媒体基金会旗下项目的默认方式。值得庆幸的是，它的执行已经成为今年官方的计划，并且自从维基媒体项目可通过HTTPS方式访问时就已经成为了非官方的计划。
我们目前的软件架构还无法默认提供HTTPS连接，但我们一直对其修改使其能够支持这一点。由于此次更改专门针对XKeyscore计划，我们将加快这些改变。下面是我们目前计划的路线图：
- 登录时重定向至HTTPS，并保持登录用户的HTTPS状态。这个改变计划在
8月21日16:00(UTC)8月28日20:00(UTC) 实装。 - 开展https基础建设：在系统缓存中缓存SSL链接，前端服务器集群也会随着前端负载增大而扩大。
- 将更多的精力放在更恰当地分配在我们前端SSL的缓存负载。在我们当前的架构中，我们使用” 基于哈希算法的负载平衡器，以允许SSL会话恢复。我们将切换到一个能够支持分布式SSL缓存的架构，否则我们将我们目前的计划制作一个。这样做将使我们切换到一个[1]，以使SSL缓存更有效率。
- 从一些小维基站点开始，渐渐地为匿名用户默认非强制启动https访问，之后逐渐使更大的项目也开始非强制启动。非强制启动是指通过更换我们网页头部分连接标志来使得搜索引擎索引https页面，而不是http页面。
- 可以考虑启用Perfect Foward Secrecy（英语简称PFS，中文名：全面加密中转）。这貌似是唯一一种在使用https的前提下还能进行流量分析、检测用户浏览活动的方式。
- 考虑为https做强制启动。强制启动意味着访问http的用户将被强制使用https加密版本。一部分国家，显而易见的例子是中国大陆，封锁了维基媒体基金会旗下项目的https连接。所以使用强制启动意味着大多中国大陆用户将很可能与绝大多数维基媒体项目说再见。正因为这样，我们认为这样做弊大于利。但我们仍将继续评估这样做是否合适。
- 考虑启用HTTP Strict Transport Security（HSTS，中文：HTTP高强度加密传输）来避免传输过程中的中间人攻击。使用HSTS也会使得我们的项目不能被很多用户访问，因为它将强制浏览器使用https访问。并且如果一个国家封锁了https，则该国的每个收到了有HSTS信息的顶条提醒的用户，将无法访问基金会的项目。
诚然我们除了已登录用户重定向至HTTPS外没有时间关注相关的任何变化，但我们会进行内部调整并将随时更新这个提议。
直到HTTPS被默认开启，我们强烈建议有隐私意识的用户使用HTTPS Everywhere或带套穿墙 [1]。
Ryan Lane
营运工程师，维基媒体基金会
[1]: 注意使用带套穿墙的用户将限制编辑；请参阅英语维基百科的此页面。