Catalin Cimpanu 发布的文章

今天, Let's Encrypt 项目正式发布了!结束了自去年十二月进入的 Beta 测试期,现在成为了一个“稳定的”产品了。

该项目启动于 2012 年,共有四位发起人,两位来自 Mozilla 基金会,一位来自密歇根州立大学,另外一位来自 电子前沿基金会 Electronic Frontier Foundation 。该项目的目标是为大量的网站提供简单而免费签发 SSL/TLS 证书的方式。

该项目起步很慢,但是在 Cisco、 Akamai 等公司以及 ISRG 加入后发展迅速。由此,它得到了越来越多的公司支持,并在 2015 年初发布了一个 Alpha 测试,并于 2015年末开放了 Beta 测试

Let's Encrypt 当前已经保护了 380 万个 HTTPS 域名

今年三月,该项目达成了其最大的里程碑,EFF 宣布它已经签发了 100 万个证书,保护了 250 万个域名。

而在这次正式发布时,据官方数据,Let's Encrypt 已经签发了 170 万个证书,保护了 380 万个域名。

 title=

由于 Let's Encrypt 让安装 X.509 TLS 证书变得非常简单,所以这个数量增长迅猛,特别是在他们和 Automattic 达成合作之后。在前几天 Automattic 和 Let's Encrypt 宣布合作之后, Automattic 说其旗下的 WordPress.com 上的博客只需要轻轻点击几下就可以安装 Let's Encrypt 证书,从而将其内容转移到了 HTTPS 上。

未来的资金充裕

在这次官方发布时,Let's Encrypt 的支持者们 Akamai 和 Cisco 也续费了他们的白金会员身份,而且一续费就是三年,以确保这个项目将来有足够充足的资金。

除了 Akamai 和 Cisco ,Let's Encrypt 也增加了新的黄金赞助商 Gemalto 以及白银赞助商 HP Enterprise, Fastly, Duda 和 ReliableSite.net 等。

一份最近的调查报告显示,HTTPS 站点中仅有 0.09% 的站点(大约 4100 个)使用了 HTTP 公钥钉 HTTP Public Key Pinning (HPKP)来增强其域名的 SSL/TLS 证书。

HPKP 是一个 HTTP 安全扩展,最初发布于 2015 年 4 月(RFC 7469)。该标准定义了一种避免浏览器访问到伪造证书的 HTTPS 网站方法。在浏览器访问 HTTPS 网站时,网站可以锁定浏览器所应接受的该网站的公钥列表;只有浏览器接受的证书同之前通过 HPKP 头所申明的一致时才能访问该网站。

为防止攻击者使用一个以你的域名签发的有效证书来伪造你的网站时,HPKP 很有用

这种机制可以用于防护攻击者运行一个假冒网站并使用有效证书来欺骗浏览器的攻击行为。

攻击者有几种方式可以得到有效的证书。他们可以通过对 CA 的社会工程攻击、对技术薄弱点的攻击、CA 的数据泄露、利用脆弱的证书签发策略等来得到。另外,如果攻击者本身得到了浏览器可信任的 CA 的授权,也是可以做到的。

HPKP 就是用来解决这种问题的。

HPKP 如何工作?

当网站管理人员为他的网站设置 HPKP 头时,第一次连接到该域名的用户将接收到一个包括了公钥指纹的列表,以后对该网站的访问必定使用这些公钥之一才能进行。

这些公钥存储在用户的浏览器里面,当用户再次访问该网站时,在建立 HTTPS 连接前,浏览器和服务器会确认它们都使用了正确公钥和服务器证书。如果不是,那么支持 HPKP 的浏览器会拒绝用户访问该网站。

这对于防止攻击者通过假冒网站来欺骗用户是一件好事,但是如果合法的网站配置错误的话,这会让你的用户几个月都无法访问你的网站了。

错误配置的 HPKP 会让你的用户无法访问你的网站

做这个调查的 netcraft 公司估计是因为这个原因才导致在该标准发布一年之后,HPKP 的使用率仍然很低。

支持 HPKP 除了需要不断的维护工作,还需要维护人员如踩钢丝般的细心,才能避免整站的访问被完全关闭掉。

“即使是网站管理员们设置好了有效策略,还需要时时注意:日常的维护和紧急处置都有可能造成阻挡合法访客的事故,而且会持续阻挡很长时间。” netcraft 的 Paul Mutton 解释说。

这就是为什么只有 4100 个网站的管理员们决定使用 HPKP 头的原因。不幸的是, netcraft 说,实际上这个数字只有 3000 左右,因为大约有 1/4 的网站的 HPKP 头设置不正确。

实现 HPKP 并不太复杂,只是需要很细心

积极的一面是,当网站管理员熟悉了如何管理白名单中的证书及其客户端密钥,HPKP 可以为大多数带有敏感数据的网站提供了必要的安全措施。

一些著名的服务已经实施了 HPKP ,比如 GiHub、Mozilla 和 Pixabay 等。

尽管如此,像 Lenovo Superfish 和 Dell eDellRoot 这样的丑闻中,他们在其产品中包含了根证书,可以让攻击者绕开 HPKP。此外如果攻击者可以访问用户的浏览器,也能修改浏览器的可信任公钥列表来取消 HPKP 防护,或者禁止用户访问合法网站而去访问恶意伪造的网站。

支持 HSTS 比你想象的更容易。

由于服务器管理员没能正确设置 HTTP Strict Transport Security (HSTS),现今大量的 HTTPS 流量都能被轻松劫持。

HSTS 是一个被当前大多数 Web 浏览器所支持的 Web 安全策略,它可以帮助 Web 管理员保护他们的服务器和用户避免遭到 HTTPS 降级、中间人攻击和 Cookie 劫持等 HTTPS 攻击的危害。

95% 的 HTTPS 连接处于风险中

据最近的 Netcraft study 报告数据显示,当前多达 95% 的服务器所运行的 HTTPS 没有正确地设置 HSTS 或其它配置,以至于将 HTTPS 连接暴露于上述攻击风险之中。

更值得注意的是,Netcraft 在三年前进行的同样扫描,不正确配置的 HSTS 比例仍同现在一样。这表明 Web 管理员们并没有学会或被告知如何正确地设置 HSTS。

针对这些不安全的站点的最容易的攻击场景是 HTTPS 降级攻击,攻击者可以选择多种方式来迫使一个看起来安全的 HTTPS 连接根本不使用数据加密或使用更弱的算法,这样攻击者就可以进行数据窃取了。

据安全研究人员称,在这 95% 的没有正确设置 HSTS 的站点中,有很多银行和金融机构的网站。

你可以通过下面一行配置激活你的 HSTS

不需要费脑筋,你只需要将下述的一行配置添加到你的 HTTPS 服务器配置中即可实现 HSTS。

Strict-Transport-Security: max-age=31536000;

这一行可以让服务器告诉浏览器仅通过 HTTPS 连接来访问其内容,其策略有效期为长达一年的最大有效时间。

当上述配置生效后,即便用户在他的浏览器中输入 URL 时写了 “http://”前缀,浏览器仍将会自动切换“https://”。

更多关于 HTTPS 及 HSTS 的技术实现细节,请参阅以下文章:

恶意软件分销商并不知道开源社区是多么痛恨网络犯罪,所以他们就被曝光到推特上了。

树莓派基金会的 传播总监 Director of Communications Liz Upton 最近在推特上贴出了一封邮件截图,邮件显示有人试图让树莓派基金会在其所有产品上安装恶意软件。

鹅妹子嘤!有人想要给我们钱让我们在你的机器上安装恶意软件。 pic.twitter.com/1soL0MIc5Z

— Raspberry Pi (@Raspberry\_Pi) December 23, 2015

试图让树莓派预装恶意软件的邮件

在该邮件中,一位名叫 Linda 的人向 Upton 夫人提出,她们公司提供一个 EXE 文件,该文件会在桌面上建立一个快捷方式,用户点击即可访问到一个特定的网站。(树莓派也可以运行 Windows,不仅仅是 Linux)

这位来自某 Q 公司的 Linda 也询问了树莓派基金会的 PPI 价格(每份安装价)。

从邮件的用语可以看出其英语并不娴熟,是业务人员,这位 Linda 应该不是来自专业公司的人员。有许多公司充当恶意软件分销商和正规公司之间的中间人,冒充广告代理公司或公关公司。

就在两周前, 数字公民联盟 Digital Citizens Alliance 和 RiskIQ 发布了一份报告称,BT 站点可以通过恶意文件或受感染的种子文件来散发恶意软件给他们的访问者,从而每年牟取了 7 千万美金

联系开源社区的公司并没有想到其邮件会被曝光

树莓派基金会有多达 5 百万的用户基础,恶意软件分销商肯定对此垂涎欲滴,希望能将他们的恶意代码隐藏在市场上最热的产品固件之中。

树莓派这块信用卡大小的廉价电脑已经用在了物联网方面,黑客可以通过它来访问到其所运行的高安全的环境中。

因为当前还没有可以运行在物联网设备上的安全软件,如果感染了恶意软件,它会持续运行很多年——直到你擦除了固件——而这在产品环境中很少发生。

如果树莓派基金会不是和 Linux 基金会关系密切,而且遵循其开放原则,让社区构建软件,我们可能就得对此担忧了。

在网上有很多人说,绝大多数的树莓派都是运行在 Linux 下,EXE 文件根本没用。其实这并不是关键。发送这封邮件的人显然没有专业水准。这篇文章真正的着眼点是,恶意软件分销商在不断地寻找可以注入他们的恶意软件的新客户端,而并不是讨论这封邮件本身的技术问题。