今日头条 第7页

大事件一：被泄露的私钥和基于假私钥进行的撤回

上个月，我们报告说Spotify和Cisco在应用程序中捆绑了有效证书的私钥。这些证书将根据基准要求被撤销，但应用程序不是泄露私钥的唯一来源。Koen Rouwhorst发现了各种属于GitHub存储库中的有效证书的私钥。你甚至能通过标准文件名（如server.key）在相应的网站上下载这些密钥。根据规定，所有被泄露的私钥都必须在24小时内由证书颁发机构撤回。于是如何彻底地测试这种密钥泄露成为了难题。（比方说，本文作者成功使用山寨密钥请求赛门铁克撤回证书。）（赛门铁克做出了如下回应。）

大事件二：TLS拦截引发争议

TLS工作组目前正在讨论Matthew Green关于如何使用静态Diffie-Hellman允许被动TLS解密的建议。这个讨论是由某银行组织抱怨TLS1.3移除了旧的RSA密钥交换而引发的。

近来，TLS邮件列表上的那些冗长的讨论以及布拉格IETF会议上的辩论都由此展开。然而至今仍没有达成什么明确的共识。斯蒂芬·切科维（Stephen Chekoway）撰写了辩论的总结。 来自Cloudflare的Nick Sullivan在发言中涵盖了争议。

本月短新闻

• 在Mozilla安全策略列表中，针对无效主机名颁发的证书启动了较长的线程。各种证书颁发机构已经颁发了包含双点的主机名的证书。
• 两家挪威报纸巨头——Aftenposten和Bergens Tidende正在使用HTTPS
• Robert Parks解释说，Microsoft Visual C ++的文档建议使用过时和不安全的加密技术。 作为回应，微软把文档删除了。
• RFC 8188引入了HTTP的加密内容方法。这意味着允许不由TLS提供的HTTP内容的存储加密。
• 众所周知，客户端证书的传输不经过加密。因而存在隐私问题。慕尼黑技术大学的研究利用了这个漏洞来跟踪Apple Push Notifications（APN）的用户。好消息是，TLS1.3将加密客户端证书。
• Let’s Encrypt 宣布从明年开始提供免费通配符证书。
• Tim Taubert解释说，Mozilla的NSS库的开发人员使用形式验证来显示作为其新的GCM实现的一部分的二进制乘法函数的正确性。
• Mike Cardwell指出，新的Lavabit服务的IMAP和SMTP服务器似乎向客户端提供未加密的登录。
• sct.rs是一个写在Rust中的库，可以从Certificate Transparency服务器验证签名的证书时间戳（SCT）。
• Troy Hunt讨论了即将到来的浏览器中HTTP证书的UI更改，并预测没有HTTPS支持的页面将面临越来越大的压力来包含此类支持。
• Cloudflare的Nick Sullivan在详细的博客文章中讨论了OCSP装订及其实现。 Cloudflare现在也使用了OCSP Must-Staple。
• LibreSSL已经发布了2.5.5和2.6.0版本。
• 在布拉格的IETF会议期间，讨论了通过HTTPS传递DNS查询的方案。 Google已经提供了一个基于HTTPS服务的DNS，但它使用的是不同的格式。
• Google，思科和Mozilla的研究人员发表了一篇关于采用HTTPS的统计资料。研究将在2017年USENIX安全研讨会上发表。
• SBA Research发表了一篇文章，调查了在Apache Web服务器上部署HTTPS的可用性。他们测试了具有IT技能的学生是否能够在一小时内配置这样的服务器。这项研究也将在USENIX安全研讨会上介绍。
• 包含锁定表情符号的IDN域名的测试网站会尝试欺骗用户相信HTTPS。然而，主流浏览器中没有一个在URL栏中显示表情符号。
• Stefan Eissing发布了第一个alpha版本的mod_md，这是Apache Web服务器的一个Let's Encrypt / ACME模块。这项工作由Mozilla开源支持（MOSS）计划赞助。
• 美国NIST已经宣布放弃三重DES（也称为3DES或TDEA）算法。其小64位块大小使其易受攻击。去年，Sweet32攻击显示了64位块密码的弱点。
• Google已经宣布最终从WoSign和StartCom在Chrome中取消所有对证书的信任。
• Vincent Lynch概述了仅通过Chrome提供的安全功能。
• 在Privacy Enhancing Technologies Symposium上发表的一篇文章研究了对BGP的新攻击和证书颁发机构的域验证过程。 Black Hat 2015曾讨论过类似的攻击。
• StartCom要求将其新的根证书包含在Mozilla的证书库中。 但是，这些证书与现有的中间证书共享私钥。
• Kelby Ludwig写了一个关于LLL算法的解释，该算法是一种基于格子的方法，可以用来攻击一些加密算法。
• Shay Gueron和Yehuda Lindell发表了一种使用密钥导出与块密码模式的方法，以提高其安全性。
• 来自Kudelski Security的Jean-Philippe Aumasson和Yolan Romailler发布了使用差分模糊测试来查找加密软件错误的工具CDF。

稿源： Feisty Duck

两大主流浏览器厂商将采用相同的时间表进行规范......

在上周谷歌提出针对赛门铁克证书事件的一系列解决方案后，管理Firefox和NSS（一组开源加密库）的根程序的Mozilla也在近日宣布将采纳谷歌的大部分决定。该计划的大致结果是：

• Symantec的现有根证书将被停用。新根将提交给根方案。
• 赛门铁克将通过合作的证书颁发机构继续发布证书，因为它经过新的根审核和分发的过程。
• 2016年6月1日之前颁发的赛门铁克证书（当他们开始证书透明度记录时）将需要通过重新发放证书（免费）来取代，或者可以提早更新。
• 2018年10月，所有从当前根源发布的赛门铁克证书将需要更换。

在Mozilla的根程序上工作的Gervase Markham表示：“我们已经决定将Google提出的针对Chrome的日期进行匹配（在几周内，确切的Firefox版本将在更接近的时间确定）。

由于Firefox和Chrome的发布时间表完全不匹配，Mozilla可能会在Chrome之前或之后实施其更改。浏览器版本只是估计，保证日期不会提前发布。因而为了迎合Firefox的要求，提前采取措施是很有必要的。

那么苹果和微软呢？

苹果和微软也管理自己的平台的根证书商店。按照惯例，两家公司都没有公开评论他们将如何处理赛门铁克。

不像谷歌和Mozilla，习惯以很大程度的透明度来操作他们的根程序，苹果和微软不会主持公开讨论或接受评论。这两个厂商一如既往地动作缓慢。

但别担心，这很正常。通常情况下他们会征求同事的意见，或者干脆不怎么变化。

至于受到赛门铁克证书事件影响的组织和网站，大可放心地针对Google宣布的计划来安排证书的更替。

除非苹果和微软的计划更早生效，否则不应与Google和Mozilla冲突。

 

稿源：The ssl store

今年三月，谷歌的Chrome浏览器团队提出了赛门铁克违反SSL证书颁发相关行业标准的问题。为了达成一个共赢的方案，谷歌、赛门铁克及互联网社区的其他成员在过去的四个月内不断进行着协商和讨论。而就在近日，Chrome浏览器团队和赛门铁克公司宣布了他们的最终推进计划。起初设定的2017年8月8日的截止日期不再适用。

如果你的网站正在使用赛门铁克的SSL证书，本文将会为你解答，查看Chrome的未来版本是否会影响您的特定证书，以及如何在一切生效之前替换该证书（免费）。

我会受这个协议的影响吗？

如果你目前是赛门铁克公司证书的用户，或计划在2017年要购买他们的证书，那么这可能会对你产生影响。

作为证书颁发机构中的大佬，受影响的赛门铁克SSL证书的数量比预想的要多。注意，赛门铁克公司运营着不同的品牌，所有这些品牌都会受影响：

• Symantec
• GeoTrust
• Thawte
• RapidSSL

Mozilla的火狐浏览器也在酝酿一系列措施，但目前还没有制定出任何计划。

值得庆幸的是，在2018年来临之前，你仍有很多时间来做准备。

Chrome对赛门铁克问题证书取消信任的计划分为两步。第一阶段，2016年6月1日以前颁发的证书将受到影响。第二阶段，所有从赛门铁克公司目前的根证书颁发的证书都会受影响（包括还未颁发的证书）。

为了遵守谷歌的计划，你需要通过一个免费的重新颁发和重新安装过程来替换现有的赛门铁克证书，但过程并不繁琐。

为什么谷歌不信任赛门铁克证书？

由于赛门铁克公司违反了行业标准，谷歌Chrome浏览器决定，赛门铁克目前的根证书（这是该公司SSL产品受信任的根本）需要由Chrome浏览器重新审核。由一系列测试证书的错误颁发引起的“血案”，促使谷歌提出对所有赛门铁克证书的怀疑。

由于谷歌所处的位置，很多赛门铁克SSL证书最终将不再被Chrome浏览器信任，如果使用HTTPS的用户未采取适当行动的话，还将收到报错。

这一过程将分为两个阶段，第一阶段从2018年4月开始，第二阶段将会在2018年10月（我们将在下一节详细讲讲这些变化的细节）。

然而，请注意，赛门铁克公司仍将可以通过使用不同的技术架构继续颁发可信证书。

赛门铁克公司将首先与另一家妥善管理的证书颁发机构合作，该机构将从今年12月开始以赛门铁克公司的名义颁发证书。在赛门铁克公司向浏览器提交新的根证书期间，这个合作伙伴将继续处理证书颁发有关事务。

这将允许赛门铁克公司在谷歌宣布做出这些改变期间不间断地继续颁发可信证书。

长期来看，赛门铁克公司新的根证书将广泛发放给各种设备，这会使他们开始自己颁发证书。

我该怎么办？

Chrome提出的两个阶段将以Chrome 66和Chrome 70两个版本的发布为节点。目前的版本是61。

Chrome 66发布时（预计在2018年4月中旬）如果未采取适当措施，所有2016年6月1日前颁发的赛门铁克证书都将不再受信。

这意味着Chrome浏览器66版本以上的用户将不能与你的网站建立HTTPS连接，并将收到一个警告。

第二阶段将从Chrome浏览器70版本发布（预计在2018年10月末）开始。如果未采取适当措施的话，那么所有由赛门铁克目前的根证书颁发的证书都将从这一天开始不受信任。

根据你当前证书的颁发和失效日期，你可能需要替换你的赛门铁克证书，以在此期间保持证书可信。这可能取决于赛门铁克公司未来的PKI改进措施的时效。

为便于了解这一系列事件，我们把这些信息分解成一个时间表。Chrome浏览器不再信任的两个阶段是截止日期，它们被加粗了，以清楚地显示一般信息和可操作步骤的区别。

(大约的) 日期	Chrome 浏览器版本	会发生什么？	怎样做准备？
2017年10月24日	62	Chrome浏览器62版本将在开发人员工具中显示一条消息，以帮助确认在Chrome浏览器66版本中将不再受信的证书。	在打开开发人员工具面板的情况下访问你的网站——这将使你明确哪个站点会在Chrome浏览器66版本中不再受信。
2017年12月1日	N/A	一家合伙证书颁发机构将开始为赛门铁克公司颁发证书。	作为终端用户，你可能会注意到颁发过程中一些微小的变化。   从技术角度看，该日期意义重大，因为这标志着“新的”赛门铁克证书的开始。   在此日期之后颁发的证书将会由不同的根证书颁发，不会受Chrome浏览器的不信任的影响。
2018年4月17日	66	所有在2016年6月1日前颁发的赛门铁克证书将不再被Chrome浏览器信任。   2016年6月1日后颁发的证书在这一版本中将不受影响。	在此日期之前替换所有2016年6月1日颁发的赛门铁克证书。   可以由你的证书提供商免费重新颁发和安装，以替换旧的证书。   如果你的证书在此期间（4-6月）失效，你可能需要考虑更新它，而不需要重新颁发，以避免短期内进行两次替换。
2018年10月28日	70	所有赛门铁克公司以其现有架构颁发的证书都将不再被Chrome浏览器信任。	从今年12月1日起，你将可以从赛门铁克公司的合伙证书颁发机构那里收到新的证书。   从技术角度看，这些证书将有另一个证书颁发机构颁发，会继续受到Chrome浏览器信任。

从Chrome浏览器62稳定版开始，当遇到一个Chrome浏览器66版本不再信任的证书时，在开发人员工具面板中，将会出现一个消息提示。开发人员可以依靠这一功能来确认他们网站中将受到影响的证书。

你还可以下载Chrome Canary版本来预览即将出现的新功能。预计Chrome 66将在明年1月推送到Canary。

或许可以这么做

为减少中断和需要做的工作，我们建议采取以下措施：

如果你的证书在2017年12月前失效···

我们建议你在12月前更新（而不是重新颁发）你的证书。这会使你在假期中拥有一个可信证书，直到2018年10月所有由赛门铁克公司现有的根证书颁发的证书都会出现问题并需要替换。

如果你的证书在12月当月失效···

我们建议你现在就考虑替换证书以避免出现中断。目前，赛门铁克公司希望在12月1日（一个星期五）前找到合伙证书颁发机构。如果你可以等到那时重新颁发和替换你的证书，你将很可能在下一次自然失效日前前不需要再替换一次证书了。

但是，注意可能会发生延迟，这就会使赛门铁克公司预估的12月1日发生问题，这可能会导致那时需要进行超常的大量证书颁发工作，从而引发技术问题。

如果出现这种情况且你现在的证书失效日期过于接近那个日期，你的证书可能会有中断的风险。“假期冻结”也可能使你不需要在这个月替换证书。

如果你必须要在赛门铁克合伙证书颁发机构做好颁发证书的准备之前替换你的证书，那么在Chrome 70发布（预计在2018年10月末）之前可能需要再一次替换你的证书。

如果你的证书在2017年12月31日后失效···

我们建议你等到赛门铁克公司的合伙证书颁发机构开始颁发证书（预计在2017年12月1日）再替换你的任何证书。

在此日期之后，你可以开始根据需要重新颁发和替换证书。

如果你的证书在2018年3月30日前失效···

早点更新证书将会是最简单的做法。这样你只需替换一次证书。赛门铁克公司的合伙证书颁发机构颁发的证书将不会受Chrome浏览器变化的影响，在其自然有效期结束前也不需要替换。

特殊情况：如果你的证书是在2016年6月1日前颁发并在2018年4月17日后失效···

你处于一种特殊情况。你的证书必须在Chrome浏览器66版本发布（预计会在2018年4月17日）前重新颁发和替换，以保持Chrome浏览器的信任。

但是，你应该2017年12月1日以后再重新颁发你的证书。在这一天，赛门铁克公司的合伙证书颁发机构将开始颁发证书。在此之前，你将只需要替换一次你的证书。

如果你在赛门铁克公司的合伙证书颁发机构出现之前重新颁发你的证书，那么你的证书将来自赛门铁克公司当前的一个根证书，它在2018年10月后仍需要被替换。

 

稿源：The ssl store

本文由网络安全研究员、securityheaders.io和report-uri.io创始人Scott Helme发布在其个人博客中。描述了如何使用Let's Encrypt的同时兼容DNS轮循。

早些时候，我所经营的securityheaders.io经历了一段负载特别高的时期。在那段时间里，我尝试研究并整理其根本原因，想在网站后端投入更多的云资源来强化它。

DNS轮循

我想转移另一台服务器，将负载从当前的securityheaders.io运行的单个实例中分离出来。计划很简单：创建服务器，向DNS添加IP地址。 DNS循环允许您在同一个域中拥有2个（或更多）IP地址，并以不同的顺序返回，以便客户端使用不同的IP地址。这个想法最终达到了相当基本的负载平衡，使得每个服务器均分50％的流量。这么做在解决了我的负载问题同时，引入了一个新问题——更新证书。

Let's Encrypt

我使用了Let's Encrypt的证书，他们通过在你主机里的某个特殊路径里放一个简单的HTML文件，来实现DV challenge。这个工作机制在仅针对一个服务器时效果拔群，但问题是，我现在有两个。要是我其中一个服务器请求证书、托管这个HTML文件，结果Let's Encrypt将我的IP地址解析成另一个服务器的IP，但这个服务器上没有响应文件，那岂不是很尴尬？证书请求失败，那就玩不下去了？幸好，我们可以用Nginx来解决！

Nginx命名地点

在Nginx中，我们通常定义一个位置块和路径。 以下是我常用的接受ACME challenge的位置信息：

location /.well-known/acme-challenge/ {
alias /home/acme/challenges/;
try_files $uri;
}

该路径将匹配/.well-known/acme-challenge/，我已将其别名到写入challenge文件的文件系统文件夹中，try_files将检查文件的存在。 这一切都很好，直到该文件可能在另一个服务器上，这就是所在的位置。try_files指令可以采用多个参数，Nginx会遍历它们，直到匹配。 我们现在可以引入另一个参数并创建一个命名的位置：

location /.well-known/acme-challenge/ {
alias /home/acme/challenges/;
try_files $uri @proxy;
}

这告诉Nginx在本地查找该文件，如果没有找到，那么将其传递给@proxy。 我们现在需要定义命名的位置：

location @proxy {
proxy_pass http://162.243.159.108:8080;
}

在这个位置，我正在使用proxy_pass指令将请求传递给另一个服务器。 第二台服务器正在监听端口8080，专门针对已经通过的ACME challenge：

server {
listen 192.241.216.219:8080;
server_name 192.241.216.219;

location / {
return 301 https://securityheaders.io$request_uri;
}

location /.well-known/acme-challenge/ {
alias /home/acme/challenges/;
try_files $uri =404;
}
}

第二台服务器被配置为监听IP，并回答ACME challenge，或将流量重定向并返回到securityheaders.io域。 我还向UFW添加了一条规则，只允许每个服务器根据其IP地址与端口8080上的其他服务器进行通信。

解决这个问题的最佳方法可能是使用DNS challenge而不是HTTP。 之前Let's Encrypt增加了对此的支持。不过可惜的是，我是用的客户端acme_tiny并不支持这项功能，而我只想走一条快速简洁的捷径。因而上述做法仅适用于几台服务器之间周转，扩展性不佳。但如果你和我一样只想快速搞定，这个方法可以一试！

稿源：scotthelme.co.uk

 

大事件一：思科和Spotify在应用程序中发送私钥

2017年6月度发生的几起应用程序传输私钥事件引发了业界关注。包括思科、Spotify、Github、Dropbox和 Discord在内的多个知名应用均被发现把私钥传给了客户端。 所幸这些证书都是之前已知且已被撤销的。

在大多数情况下，证书的意图是为了让应用程序打开本地Web服务器，以便公司的Web服务可以在浏览器中与服务器进行通信。随着越来越多的网页移动到HTTPS，如果本地服务器没有有效的证书，则此过程将被阻止。

人们对于浏览器是否应将本地主机IP（例如127.0.0.1）视为安全来源的问题进行了讨论。就算本地主机使用的是未加密的HTTP协议传输也能称作“安全”吗？未来的浏览器可能允许这种做法，而不需要运送证书和密钥。但是，CA或浏览器的基准要求禁止这种做法。如果私钥公开，则相应的证书会被撤销。

短新闻

苹果全球开发者大会上宣布了LibreSSL、TLS 1.3 Beta版、新的证书吊销检查机制。

上周苹果公司召开了年度全球开发者大会。会上的重大消息之一就是苹果的High Sierra for macOS、iOS11、tvOS11和watchOS4等新版操作系统的发布。

苹果公司花费了一些工夫讨论他们各平台加密库和SSL/TLS支持的改善情况。

下面，我们对所有这些改变做了一个概述，其中的大部分已在“你的App与不断进步的网络安全标准”会议上宣布过。

新的证书报错界面

High Sierra系统的证书查看器和Safari浏览器，重新设计了证书报错界面。

在Safari浏览器中，新的报错页面被设计为，通过给出一段简明的英文来解释问题，而没有使用像“协议”或“签名”这样的术语。这与Chrome浏览器的界面有些类似。

证书查看器会进一步显示更详细的信息。在下面的截屏中，你可以看到，屏幕上显示了一个警告，具体说明了该信任错误的详细内容。在这个例子中，该错误提示“此证书无法核实（弱摘要算法）”，是因为该证书是通过SHA-1进行签名的。

改进后的证书吊销检查机制

苹果公司发布了一种新的适用于其所有平台的证书吊销检查方法。它还未取得适宜的名字，不过它与Mozilla的OneCRL运行方式相类似。

苹果公司的方法是，先扫描证书透明系统日志来发现他们的平台所信任的证书。然后再从证书颁发机构查询已发现的证书吊销状态。已吊销证书的所有相关信息都被捆绑在一起，在静默状态下每隔一段时间会被自动分发给客户端设备（如Macbooks和iPhones）。

当建立一个TLS连接后，客户端会进行检查，验证证书在中央列表中是否被标记为吊销。如果证书被标记为吊销，那么客户端将会执行一个活动的OCSP检查，来确定这条信息是否准确。一旦确认，客户端就会知道该证书已被吊销，然后就会拒绝建立连接。如果服务器提供一个绑定的OCSP响应，那么它将会用这个响应来进行确认，而不需要执行活动的检查。

如果证书在中央列表中没有被标记为吊销，那么OCSP就不会被使用。

为LibreSSL而放弃OpenSSL

在High Sierra系统中，苹果公司已经将SSL库从OpenSSL0.9.8zh转换到LibreSSL2.2.7了。LibreSSL是OpenSSL的一个分支，受OpenBSD支持。

“安全传输”是苹果公司自己为SSL/TLS开发的API，但其首先应用于他们自己的软件。LibreSSL也将作为第三方软件的SSL库。

任何一次苹果全球开发者大会都未声明这一点，但这被High Sierra系统beta版用户发现了。

扩展ATS豁免

Chris Wood是苹果公司的“安全传输”项目工程师，他谈到App传输安全（ATS）的应用。Wood解释说，开发人员向苹果公司反馈说，过渡期比预想的要长，收到这一反馈后，苹果公司正在扩大对ATS豁免的支持。

Wood强调，苹果公司仍然会全力推动经由ATS的HTTPS，开发人员在努力进行向HTTPS的正确过渡时，他们对这些豁免的信任应是暂时的。

新苹果操作系统现在会对以下框架支持ATS豁免：AVFoundation、WebView和Webkit。豁免对本地网络连接（Ip地址和不合格的主机名）将会是可配置的。

豁免可以被限制在一个特定的域名，或是整个app中。我们还有一个办法来确认你是否想要对一个主机名的证书进行证书透明检查。

TLS 1.3 Beta版

TLS最新版1.3还没有被国际互联网工程任务组（IETF）确定下来。High Sierra和iOS 11系统支持TLS 1.3的一个规范草案，该草案较最终版本将十分接近。这使得开发人员在TLS 1.3正式确定前就已经开始对其进行测试了。

Chris Wood强调了TLS 1.3中更短的握手时间。他分享了苹果公司的分析数据，数据显示，在蜂窝网络上建立的TLS连接中有10%花费了800毫秒或更长时间，而在Wifi网络上建立的TLS连接中有10%花费了500毫秒或更长时间。而由于TLS 1.3具有更高效的握手方案，这个时间可以减少三分之一。

你需要从这个链接下载一个配置文件并进行安装，然后就可以在iOS 11系统中启用TLS 1.3了（需要苹果开发人员账号）。

通过以下终端命令，就可以在macOS High Sierra系统中启用TLS 1.3草案：

defaults write /Library/Preferences/com.apple.networkd tcp_connect_enable_tls13 1

结束对SHA-1和2048位以下的私钥的支持

苹果公司的平台马上就可以迎合行业标准对老化的散列算法和加密方法的弃用要求了。

以SHA-1算法和/或使用2048位以下私钥签名的证书将不再被High Sierra、iOS 11、watchOS 4或tvOS 11系统信任。

对这一改变还有一些豁免。通过移动设备管理（MDM）机制或由Safari、Mail、Keychain Access分发的证书可以继续使用这些弱散列和密钥。（用于交互验证的）客户端证书也没有受到影响。

SHA-1签名的根证书也未受影响，因为这些证书的签名验证机制并不相同。使用2048位以下密钥的根证书在2015年已从苹果平台移除。

这些要求不应该引起对那些使用现代CA签名证书的任何担忧。SSL行业标准已经禁止这些弱应用一段时间了。

开发人员将可以通过一个唯一的错误代码识别这个问题：“InvalidCertChain (-9807)”。在URLSession/URLConnection中会返回这一错误代码。因为苹果公司正准备完全放弃对这种情况的支持，所以解决这一错误的唯一的方法就是替换你的证书。

RC4和3-DES将会被移除

“安全传输”的工程师Bailey Basile强调，“在将来”，RC4和3-DES这两个老化的密码算法，会被苹果公司的所有平台弃用。虽然还没有给出准确日期，但开发人员应该开始逐渐远离这两种很久以来即被公众所知的弱密码了。

Basile还建议避免在CBC模式中使用AES（AES-CBC）。他建议的密码套件是AES-GCM或ChaCha20-Poly1305。

 

稿源：The ssl store

由于性能降低，Mozilla将会尝试禁用OCSP检查。OCSP，或称在线证书状态协议，是用来检测证书是否已被撤销的一个技术性机制。Firefox的这一变更将会同即将推出的新测试版本Nightly一同出现。如果遥测数据证明了禁用对DV和OV证书的OCSP检查可以减少握手时间，这一做法将会被带到标准版。

这将使Firefox与其他主流浏览器（包括Chrome和Safari）相提并论，其中服务器向客户端直接提供OCSP响应的OCSP装订将不会受到影响。此外， Firefox还将继续为EV（扩展验证）证书提取OCSP响应。

OCSP长期被批评为鸡肋。 由于在全球范围内部署服务的操作性挑战，OCSP通常在“软失败”的情况下终止 - 这意味着在OCSP检查未完成的情况下（因为服务器关闭或连接超时），证书被认为是有效的。因而一旦发生这种状况，OCSP就形同儿戏。 谷歌的工程师亚当·兰利（Adam Langley）甚至嘲讽它为“崩溃时扣上的安全带”。

Mozilla的遥测数据显示，在成功的OCSP检查中，大约9%的检测花了超过1秒的时间。这一秒加在了SSL/TLS握手上，从而大幅延长了整个页面加载的时间。更有甚者（0.05%的OCSP检查）超过3秒！这能忍？

无独有偶，Let's Encrypt的OCSP服务也在上月早些时候下线了12个小时，影响了不少使用他家证书的用户。去年GlobalSign也被他们的OCSP服务器坑了一回。这些事件都让人不禁疑问，OCSP这么闹心真的还要继续用吗？

Mozilla的安全工程师David Keeler写道：“这次禁用是为了监控遥测数据，看看OCSP是不是真的影响TLS握手时间。”要是真的有用，他们将会在所有Firefox版本中禁用OSCP检查。

其实早在多年前OCSP的性能就已经提升了不少——OCSP装订和Must-Staple的出现都旨在修复性能、安全性和隐私问题。然而不开窍的其实是Apache和Nginx，作为两大最主流的web服务器，他们在OCSP的特性实施上乏善可陈。因而到底坑货是谁？这话还真不好说。

稿源：The ssl store

上周五，谷歌和赛门铁克促成了一项提议，将允许赛门铁克在一定条件下继续颁发SSL证书。这是继今年年初被发现违规误发证书和被谷歌提出取消信任之后，赛门铁克与谷歌的第一次正式协商方案。

谷歌和赛门铁克都指出，提议中的一些具体细节可能会改变，但是他们趋近于“一个解决安全风险和减轻中断的良好平衡的提案”。

之前的谷歌提案涉及到对赛门铁克证书的一系列复杂的限制，以及对现有证书的分级不信任。这将使赛门铁克及其客户陷入棘手的境地，因为赛门铁克将不得像与其他CA一样提供相应的服务。

根据新提案，赛门铁克将与其他CA合作，继续发行证书，同时重新启动自己的业务。执行此计划所需的大部分工作将由赛门铁克本身进行。用户将看到相对较少的更改，并且可以获得对他们没有任何限制的新证书。

对于浏览器，将新旧的赛门铁克证书与新的根证书分开是非常重要的。这使他们有能力通过技术措施来控制哪些证书是可信的，而不是那些听上去更靠谱的政策。

这个提议的亮点在于：

• 与以前的计划一样，这些操作适用于所有赛门铁克运营的CA，其中包括GeoTrust，Thawte和RapidSSL。
• 从8月8日起，赛门铁克证书将需要由“托管CA”发出 - 赛门铁克与其合作的另一个认证机构。 目前还不知道谁将与赛门铁克合作。

这些证书将由现有赛门铁克根证书交叉签署，可以让信任赛门铁克的现有根源的各种传统设备的新证书受到信赖。

• 此管理CA颁发的证书不会面临任何独特的限制。这意味着赛门铁克证书将能够按照行业标准规则颁发。他们的EV证书将继续使用绿色地址栏UI显示。
• 2016年6月1日之前发布的现有证书（当赛门铁克证书需要遵守Chrome的证书透明度政策时）需要更换。 Chrome将在8月份的两个阶段（Chrome 62的发行版）中不信任这些证书。
• 2016年6月1日以后发行的现有证书不受影响。这些证书的所有者不需要重新验证/重新发行，或看到有效期的任何减少。 EV证书将继续拥有EV UI。
• 尽管如此，赛门铁克还将向谷歌和社区提供审计和报告，以显示其修复导致其违规的错误的进度。他们还将努力向根程序提交新的根证书，以便在技术上可行的方式再次开始验证和颁发证书。

赛门铁克的合作伙伴CA将继续处理发行和验证，直到赛门铁克的新根证书被接受到信托商店。对于任何一家公司来说，这都不算什么，包括经验丰富的CA。虽然一些根源程序（如Mozilla）是透明和有据可查的，但其他（比方说苹果）就像城市传说一样，可以花更长的时间来处理。

赛门铁克可能需要两年或更长时间才能将所有内容重新置于内部。但与此同时，他们的客户将继续能够购买和使用证书，而且没有复杂或不方便的限制。

再次注意，这还不是一个最终的计划。虽然这个过程看起来很艰巨，但考虑到赛门铁克业务的规模是有道理的。赛门铁克星期五表示，“仔细审查这项建议，并将尽快回应社区的意见反馈。”我们预计将尽快进行最后的调整，届时我们将发布有关即将发生的变更和行动的更多细节赛门铁克证书用户需要做好准备。

Mozilla与谷歌类似：它提出了一个仍然需要进行微调的计划。 它与谷歌非常相似，其中一个主要区别是赛门铁克证书将限于400天的有效期。 Mozilla也在辩论这样的想法，即在新的PKI启动时，赛门铁克需要外包CA的职责。 Mozilla意识到赛门铁克将不得不遵循所有根目录中最严格的规则，因此Mozilla正试图将其计划与谷歌的相提并论。

同行业的规范一样，微软和苹果都表示很少，也没有公开声明他们将要做什么。 历史上，他们的根程序更宽松，因此在确定对用户的影响时不太重要。

稿源：the ssl store

上周五大规模传播的WannaCry勒索软件让一群网络安全专家意外地团结起来。

WannaCry勒索软件的故事类似于好莱坞剧本，它像野火一样蔓延 - 从欧洲开始 - 感染了超过20万台电脑，其中包括英国国家卫生服务部门的大部分医院和医生办公室关闭非紧急服务。

该勒索软件利用了一个由美国国家安全局（NSA）发现的微软Windows漏洞，随后被影子经纪人泄露，并在两个月前进行了修补（如果您还没有，现在就重新进行补丁）。这种特殊的攻击使得WannaCry在感染组织内的设备方面特别有效。然后，一个匿名研究人员偶然发现了如何通过注册域名来制止攻击。英国媒体在周末曝光了改名研究员的真实身份，微软则把锅甩给了NSA，指责他们惹了大麻烦。

经过一个周末的努力，许多IT专家和研究员都已做好了面对新一周变种危机的感染。如果你是那个勒索软件作者，成功地攻击了全球近25万个设备和主要公司，包括雷诺和联邦快递，你期望这回能挣多少钱？

绑架一台电脑能赚多少钱？

首先，我们来看一下赎金要求。 一旦感染，WannaCry加密你电脑中的文件，并要求在比特币上支付300美元。 三天后，赎金飙升至600美元。

WannaCry提供了三个比特币付款地址，虽然比特币支付方式是匿名的（仅显示发件人和接收方的比特币地址），但所有交易都被公开记录在块中。因此要看出WannaCry作者的收入多少并不是件难事。查看块链接数据可以看出传送的比特币数量，发件人和收件人的比特币地址以及交易时间。

截至周一下午，WannaCry的三个比特币地址已经收获了215笔赎金。但其中35笔低于1美元，15笔低于25美元。许多付款都出自同一个人，很有可能是研究人员在测试这个勒索软件。

另外两笔款项大约在50刀左右——比测试款多，但远不及攻击者要求的赎金。这可能是系统出了错或是受害者和攻击方达成了某种协议。

而剩下的163笔费用则更像是真正的赎金——从168美元到3424美元不等。总计51644美元。超过两万美元的赎金都是在周一完成的交易。

虽然比特币可以直接用于购买一些物品，但是犯罪分子需要能够将其收取的赎金转为美元（或其当地货币），才能用得了。但考虑到该事件引发的巨大关注，要想将比特币安全地转换成真实货币可能是一个问题。

因此，现在这些罪犯并没有真正赚到一分钱。没有任何赎金已经从任何相关的比特币地址撤回或移走。一旦罪犯兑换这笔钱就会暴露身份，因为这笔钱也从来没有被使用过。

 

勒索软件如何“发家致富”？

尽管WannaCry已严重瘫痪，他仍然成功地感染并加密了超过10万台电脑。成千上万的受害者面对勒索只有三个选择：支付赎金，处理数据丢失，或等待研究界开发个解密器。

在接下来的几天内，随着企业和用户对恢复数据的需求，所收集的总赎金将大幅增加，每小时都有更多的赎金在支付。

许多公司的业务都被迫关闭，运维人员没日没夜地加班加点处理感染和估算损失。即使是手里有着所有重要数据备份的公司也要花费数小时的时间恢复机器或确保每台机器都装上补丁。而与此同时，微软提供的MS17-010补丁的带宽费用可能超过了犯罪分子收集的5万美元。

另一方面，这次攻击暴露了那些主流机构缺乏维护机器安全的意识。开个windows自动更新装上两个月前就发布的补丁，早就没WannaCry什么事了。

WannaCry已经变种了，赶快安上补丁才是正事儿！赶紧自救吧！

 

稿源：the ssl store

 

Google的证书透明度（CT）项目有望成为SSL生态系统最重要的改进之一。但老话说得好，好的事情值得等待。虽然证书透明度已经开始运行，但对于大多数CA来说，它是可选的。 这意味着CT无法完全发挥作用，因为并不是所有正在颁发的证书都被它知晓。

Google的Chrome浏览器将通过将CT记录强制要求所有希望被信任的SSL证书来解决这个问题。 但是强制性证书透明度合规的日期已经推迟了6个月 - 从今年10月到2018年4月。谷歌在4月底几个星期前宣布了这个消息。这条消息是在Google主持了“CT Days”会议后发布的。这个历时两天的会议集结了CA、CDN、日志操作员以及所有涉及或受证书透明度影响的代表。 而这个会议的结论就，整个行业都需要更多的时间来确保一切都完全准备好，以进行生态系统范围的推广。

Chrome的工程师之一Ryan Sleevi指出，在接下来的六个月里，他们希望看到“除了Chrome之外，还有助于保护其他浏览器用户的部署。”去年，Firefox宣布将支持CT，但尚未提交执行日期。

Chrome还在努力实现一个新的HTTP头，expect-ct，这将允许服务器运营商测试他们的配置和证书在最后期限之前是否都设置正确。

不可否认的是，证书透明度是SSL生态系统的一个重大变化 - 这同时面临技术挑战，对于企业部门来说，他们认为所有证书都可以公开发布。

例如，今年早些时候，东海岸的亚马逊S3云服务中断导致了Venafi的日志失败 - 展示了可靠运行日志的要求。同时，IETF仍在完成一些标准工作。

此外，CT还面临一些”隐私问题“，尤其是对于那些主机名公开构成安全隐私风险的企业部门。“名称修改”仍然存在争议 - 这将允许对CT日志中的主机名进行部分审查。谷歌对大多数这些担忧仍然持怀疑态度，嘲讽这些”问题“是过时的威胁模式和对改变的莫名恐慌，而不是合法的风险。

但毫无疑问，证书透明度将为生态系统带来巨大的好处。即便它只是被部分采纳，CT已经抓取到了一定数量的威胁。

 

稿源：the ssl store