维基百科:强制加密登录/博客原文

此页面目前处于闲置状态，仅供历史参考而保留。
此页面最后更新于2018年11月16日 (五) 06:14 (UTC)。此页面的内容可能已无明确的共识支持，或是不再与讨论的主题相关。若您希望重启讨论，请至互助客栈寻求更广泛的意见。

翻译内容可能有不准确的地方，欢迎校对翻译。可能不准确的部分使用斜体标注。翻译内容仅供参考。如果您对http,SSL协议或HTML语言有所了解，请参与校对翻译。

由Ryan Lane于2013年8月1日发布。
维基媒体基金会非常重视保护读者和编辑者的隐私。最近被曝光的棱镜项目促使着我们要使用https作为社区会员访问维基媒体基金会旗下项目的默认方式。庆幸的是，它的执行已经成为今年官方的计划。并且自从部分语言的维基媒体项目可以使用https访问时就已经成为了非官方的计划。

我们当前不能默认使用https访问，但是我们已经逐步进行改进使其成为可能。当我们成为棱镜项目监控的目标时，我们加快了努力的速度。这是我们当前的路线图：

强制转向https来登录，并且将使登录进去的用户锁定在https访问。这项改动预计会在8月21日16时（UTC）执行。
开展https基础建设：在前端缓存中缓存SSL链接，前端服务器集群也会随着前端负载增大而扩大。^{[注 1]}
将更多的精力放在更恰当地分配在我们前端SSL的缓存负载。在我们当前的架构中，我们使用基于哈希算法的负载平衡器，以允许SSL会话恢复。我们将切换到一个能够支持分布式SSL缓存的架构，否则我们将我们目前的计划制作一个。这样做将使我们切换到一个加权轮循负载平衡器，以使SSL缓存更有效率。^{[注 2]}
从一些较小的项目开始，渐渐地为匿名用户默认非强制启用^{[注 3]}https访问，之后逐渐使更大的项目也开始非强制启用。非强制启用是指通过更换我们网页头部分的rel="canonical"标志来使得搜索引擎索引https页面，而不是http页面。
可以考虑启用PFS（即Perfect Foward Secrecy（英语：Perfect forward secrecy））。这是唯一一种能够在使用https的前提下还能进行流量分析、检测用户浏览活动的方式。
考虑强制启用^{[注 4]}https。“强制启用”意味着强制讲访问http的用户重定向到这些页面的https版本。有一些国家，如其中最大的一个——中国，封锁了维基媒体基金会旗下项目的https连接。所以使用“强制启用”意味着大量的用户可能根本不能够访问我们的项目。正因为这样，我们认为这样做弊大于利。但我们仍将继续评估这样做是否合适。
考虑启用HSTS（HTTP Strict Transport Security）来避免传输过程中的中间人攻击。使用HSTS也会使得我们的项目不能被很多用户访问，因为它将强制浏览器使用https访问。并且如果一个国家封锁了https，则该国使用者的浏览器一旦进行HSTS握手，连接就会被重置。^{[注 5]}

事实上，除了将登录用户跳转至HTTPS链接，我们还没有为任何改变定下期限，但是我们将内部的定下期限，并更新这篇文章。 ^{[注 6]}

直到https被默认打开之前，我们敦促注重隐私的用户在所有地方使用HTTPS或使用Tor^{[注 7]}。

Ryan Lane

维基媒体基金会，作业工程师

注释

^ 原文：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.
^ 原文：soft-enable
^ 原文：hard-enable
^ HSTS信息储存在header中吗？原文：then every user in the country that received an HSTS header would effectively be blocked form 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.
^ 原作者注：使用Tor有一些限制，见这里（英语）。

外部链接

著作权

本文作者为Ryan Lane，根据CC-BY-3.0协议发布。翻译版本由于维基百科编辑的限制，与其他维基百科编辑一样使用CC-BY-SA-3.0协议和GFDL协议发布。

[1] 原文：Move the SSL terminators directly onto the frontend varnish caches, and expand the frontend caching clusters as necessitated by increased load.

[2] 原文：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.

[3] 原文：soft-enable

[4] 原文：hard-enable

[5] HSTS信息储存在header中吗？原文：then every user in the country that received an HSTS header would effectively be blocked form the projects.

[6] 原文：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.

[7] 原作者注：使用Tor有一些限制，见这里（英语）。

[注 1]

[注 2]

[注 3]

[注 4]

[注 5]

[注 6]

[注 7]