关注网络安全
和行业未来

谷歌将在今年9月取消“安全”标识

最后甚至会从Chrome的UI中取消挂锁图标。。。

谷歌爸爸在上周四的博文中提到,他们将在今年9月发布的Chrome 69版本中移除“安全”标识。这么做的目的是为了进一步推进全网加密。

自从我们在Chrome中引入安全标识,网络上的HTTPS使用情况变得十分显著。既然那么顺,我们决定顺水推舟移除这个标识。因为用户的体验应当建立于网络默认情况下是安全的,而在出现问题时才会被警告。鉴于我们马上要着手标记所有HTTP网页为“不安全”,我们将逐步移除Chrome的积极安全标识,以便默认未被标记的网站才是安全的。这个计划预计从今年9月的Chrone 69开始执行。

尽管Chrome的“安全”标识UI总被人津津乐道,这其实并不是一个很好的点子。毕竟这年头霸屏使用的HTTPS的网站里,有很多是钓鱼网站。明明是钓鱼网站,却偏偏因为用了HTTPS而被标记成了安全,显然是不合理的。现在谷歌提出的作法,或许能改善如今的局面。所以新的UI会长这样:

在目前的最新版本,即Chrome 67中,谷歌已将协议头https省略了。更进一步,将仅留下挂锁。最后完全取消所有标识。

负责Chrome安全的谷歌产品经理Emily Schecter在近日发布了个keynote解释为什么谷歌决定不再显示协议、进一步简化地址栏的UI的原因。

此外,从Chrome 70开始(今年10月发布),谷歌将进一步丧心病狂地加强“不安全”标识的显示和波及范围。比方说,你在HTTP页面里连字都打不了。

这个新的UI意味着EV证书会成为所有SSL证书中唯一一个带皇冠会员特殊标记特权的。而许多非CAB论坛的会员,早在N年前就讨论着要把EV证书的标识给做掉了。

世事难料,对谷歌的这一决定,您怎么看?

 

稿源: The ssl store

 

虚张声势?谷歌将强制证书透明度期限挪至Chrome68

说好的四月三十日没能实现,强制证书透明度还得等到七月份。

上周我们在文章中提到,所有在2018年4月30日签发的SSL证书都必须记载到证书透明日志,不然用户在浏览网站时就会收到整页的不安全警告。然而事与愿违,尽管从证书透明制诞生以来各大浏览器厂商都在尝试将其实践,谷歌去年还给了证书颁发机构一年的时间、推迟了进程。

而这回,谷歌给的信息显得更含糊,让人难以解读。 例如,CT截止日期已过,但谷歌直到7月份才开始执行。 谷歌其实可以明确表示,这只会影响在截止日期之后发布证书的网站。也就是说,2018年4月30日之前发布的任何证书都不用载入证书透明制。

事实上,4月30日的截止日期是针对证书颁发机构的。这仅仅是业内变动,与客户无关。如果现在一家CA给你发了张没进证书透明制的证书,那基本上是误签发没跑了。要是你运气不太好,真得了张这样的证书,你在Chrome 68发布之前(7月中旬)还有机会做调整。等到7月份Chrome 68正式版发布了,使用不进证书透明制的证书才会真正波及您的用户。

有一个方法可以帮助您查看自家的证书是不是符合标准,会不会触发警告:

希望测试新颁发证书以符合合规性的站点操作员和CA可以从Chrome 67开始在开发者工具中使用这个功能。“安全”面板将提供有关连接和证书的详细信息,包括连接和证书是否适当地支持证书透明。或者,对于想要测试被主动阻止的使用非法证书的站点管理员,可以通过以下命令行标识来实现:

--enable-features=”EnforceCTForNewCerts<EnforceCTTrial” --force-fieldtrials=”EnforceCTTrial/Group1” --force-fieldtrial-params=”EnforceCTTrial.Group1:date/1525132800”

因此请大家不要担心。证书颁发机构们早就花了几年的时间成为CT认证了。大多数用户的警告将不会在7月生效。

 

稿源:The ssl store

四月行业新闻回顾

本月大事件:证书透明记录成强制

从4月30日开始,Chrome浏览器将要求所有新证书符合证书透明度。 这是证书生态系统中的一项重大变化,已经准备了好几年。 证书透明度在许多证书颁发机构发现错误的案例中已经发挥了重要作用。

证书透明度的核心思想相对简单:所有公开发布的证书都存储在公共附加日志中。 这些允许每个人检查是否已颁发其域名的非法证书。 为了显示证书已经被记录,在TLS握手期间必须提供两个所谓的签名证书时间戳(SCT)。 SCT是来自日志的已签署声明,用来确认已提交证书。

交付SCT有不同的方式,但最常见的方法是直接将其添加到证书本身。大多数证书颁发机构会自动执行此操作,因此网站操作员无需手动执行任何操作。由于CA在颁发证书之前不能记录证书,因此这些嵌入证书的SCT需要颁发的证书须包含特殊的扩展名,并且与最终证书相同,除非它缺少SCT。

那么问题来了,是不是只记录预证书就行,而不用包括最终的证书呢?Let's Encrypt最初决定只记录预证书,但如今也开始尝试记录最终证书

尽管证书透明度日志记录现在是新证书的一项要求,但流氓或受感染的CA仍然可以通过回溯来创建未记录的证书。 这可以通过使用Expect-CT标头来防止。

Hardenize服务添加了对证书透明度合规性的检查

短新闻

稿源: feisty duck

Chrome 66发布:几百万张SSL证书被取消信任

谷歌刚刚在所有主要平台上推出了Chrome 66的稳定版本,可以公平地说,并不是每个人都会喜欢它。 这是因为谷歌已经对当前受赛门铁克保护的网站及其附属证书颁发机构给予了第一次打击。 任何在2016年6月之前发布的Symantec,GeoTrust,RapidSSL和Thawte SSL证书现在都不受Chrome 66的信任。2016年6月至2017年12月期间发布的任何证书都需要在2018年10月23日之前重新签发。

谷歌对赛门铁克SSL证书的不信任是一个可追溯至2016年的事实。它始终(并且仍然)是其长期计划的一部分,并将最终停止信任赛门铁克现有PKI颁发的所有SSL / TLS证书。任何受到影响的网站都需要立即从收购赛门铁克CA业务的DigiCert重新颁发证书(免费)。

Chrome 66中的新功能

除却人们最为关注的赛门铁克证书不信任计划,Chrome 66还包含了两个不可忽视的新功能。其中之一是对自动播放视频的自动音频沉默。也就是说那些一打开就会自动放歌或广告视频的网站将不会再困扰到你。Google本计划在Chrome64版中引入该功能,但无论处于什么原因,它都被推迟了。今次出现在Chrome 66中无疑是一巨大亮点。

另一个重大的改进是“网站隔离”。其实谷歌在Chrome 63中就有这个功能了,但是没开启默认。这次该功能被设置成了默认。尽管该功能处在试用阶段,且只有少量用户在用,它依旧有望在不远的将来被每个用户掌握。

站点隔离有助于单独站点的单独进程。 换句话说,每个开放网站的内容都被视为一个不同的进程。 这会带来更好的性能和更高的安全性。 就算其中一个选项卡崩溃,整个浏览器也不会冻结,从而提高了性能。就安全性而言,站点隔离会阻止代码注入攻击,因为它不会让一个页面与另一个页面进行通信。 因此,黑客无法在Chrome的Sandbox流程中注入恶意代码。 网站隔离唯一的缺点是它可能会将Chrome的内存使用量增加10-20%。

使用Chrome 66,您可以将保存的密码导出到其他浏览器。 除此之外,Chrome 66还整合了62个安全修补程序。 如果您还没有收到Chrome 66更新,请不要担心,因为它正在分阶段推出。 到本周末,它应该到处可用。

 

稿源:the ssl store

安卓P将默认所有app使用HTTPS

下一版本的安卓系统将在app中默认阻止所有HTTP流量。Android的工程副总裁Dave Burke在博客文章中称,这是“将所有网络流量从明文(未加密的HTTP)迁移到TLS的更大努力中的最后一步......你现在需要通过TLS建立连接,除非你明确为特定域使用明文。“

这将适用于所有面向Android P的应用程序。任何需要HTTP连接的内容必须提交特殊声明。在网络安全配置文件中设置。您将可以允许或禁止HTTP流量连接到特定域或整个应用。如果你不能保证所有连接都是HTTPS流量,比方说由用户提供的URL,则应该通过要求使用HTTPS以保护与自己服务的连接这些域名。Android开发者博客文章中提供了这些配置的示例。

苹果公司在iOS和macOS上有类似的功能,名为App Transport Security(ATS)。 自iOS 9.0(2015年9月发布)以来,该功能默认开启,并要求应用程序添加自定义配置文件以允许HTTP流量免除。 此外,ATS通过仅允许TLS 1.2和提供前向保密的密码来执行“强大的”HTTPS连接。

Android安全的高级软件工程师Chad Brubaker直接阐述了HTTPS的一个普遍的说法:有些网页是“敏感的”,需要加密,而对于保护其他类型的网页(如博客或静态主页)并不重要。

HTTPS不仅仅是保护发送给访问者的数据 - 它还关乎保护整个连接。 如果没有提供防止DNS欺骗和内容注入的身份验证的HTTPS,则任何给定的连接都可能被误用来通过跟踪它们或窃取或注入数据来损害客户端设备。

Brubaker写道:“所有流量都应该加密,无论内容如何,因为任何未加密的连接都可以用来注入内容,增加潜在易受攻击的客户端代码的攻击面,或跟踪用户。”

Android P计划于2018年第三季度发布,目前可用作开发预览版。

 

稿源:DigiCert blog/the ssl store

三月行业新闻回顾

本月大新闻:Trustico玩脱 坑货证书经销商可能带来密钥风险

与证书经销商Trustico有关的几个事件引起了关于为其用户生成密钥的证书销售商的部署问题。

Digicert的Jeremy Rowley在Mozilla安全策略邮件列表中报告,他被Trustico要求撤销大量以前的Symantec证书。 赛门铁克最近被Digicert收购后,浏览器供应商计划不信任现有的赛门铁克证书。 Trustico是一个证书经销商,用于销售赛门铁克证书并转换为Comodo证书。

Rowley拒绝撤销没有泄露迹象的证书,并提到一个这样的迹象将暴露这些证书的私钥。 之后,Trustico向Rowley提供了大部分(但不是全部)被要求撤销的证书的密钥。 随后,属于这些私钥的证书被吊销。

事实证明,Trustico保存了大量用户在其网页上购买证书时使用的私钥。一些证书颁发机构和经销商为用户生成密钥是一种常见做法,尽管这样做颇具争议。

证书颁发机构没有必要访问私钥。创建证书的更安全和既定方式是用户生成私钥和证书签名请求(CSR),但有人认为这种方法太复杂。 Trustico明确宣称他们可以提供没有CSR的证书。

在这些事件展开之后,一些人检查了Trustico网页的安全漏洞,并且有人发现了一个极小的脚本注入漏洞,允许在具有root权限的服务器上执行命令。

尽管证书颁发机构需要执行审计,并且要遵守相当严格的规则,但对于经销商来说,没有这样的规则。但是,应该指出的是,这些事件都没有影响到生态系统的安全。像Trustico这样的经销商通常不能直接访问证书颁发和域验证系统,因此不能为任何人发布恶意证书或危及其他客户的密钥。

短新闻

  • TLS 1.3已经获得IETF的批准; 最终的RFC可能会很快推出。
  • 即将完成的TLS 1.3再次开始了关于拦截代理和数据中心可见性的讨论。 英国国家网络安全中心参加了这场辩论,但是正如Adam Langley指出的那样,有一些事实上的错误主张。 特别是,在1.2版本之前的TLS版本中,截取流量方法的一些误解是造成延迟TLS 1.3几个月的部署问题的原因。 在伦敦的IETF会议上,可见性问题也再次提出。
  • OpenSSL正试图将其代码更改为Apache许可证。 他们现在正在寻找最后的贡献者,目前还没有得到他们的更改许可证的批准。
  • Facebook推出了一项功能,该功能将主动将HTTP链接重写为HTTPS,以获取位于HSTS预载列表中或设置HSTS标头的URL。
  • NSS发布了3.36版本,并将其Chacha20算法替换为HACL *项目的正式验证版本。
  • 谷歌解释了其最终计划,摒弃下个月的一些赛门铁克证书以及今年晚些时候的所有剩余的证书。 正如我们上个月报告的那样,仍然有许多网站使用这些证书,这些证书很快就不再受信任,并且已经在Firefox Nightly和Chrome Beta版本中引发警告。 Mozilla TLS天文台提供了有关该主题的一些新数据
  • Apple已经对HSTS进行了一些更改,以防止滥用用户跟踪功能。
  • Android P将加强对应用程序中TLS流量的需求,如果开发人员未明确选择加密流量,则会阻止所有非TLS流量。
  • Mozilla通过HTTPS测试DNS的实验引起了一些争议。 这意味着DNS查询会通过加密通道转到Mozilla控制的服务器。 从隐私的角度来看,这既有利也有弊:流量本身是加密的,无法读取,但是一个中央服务器(在Mozilla的情况下,使用Cloudflare)可以访问大量的用户DNS数据。
  • 自动化证书颁发的ACME规范正在终审,并可能很快成为IETF RFC。
  • encrypted.google.com子网域提供了一种通过HTTPS访问Google搜索引擎的可选方式。 现在已经被弃用了,因为搜索引擎默认已经通过HTTPS访问了一段时间。
  • Hanno Böck 发布了WolfSSL库中堆栈缓冲区溢出的详细信息
  • Let's Encrypt现已支持通配符证书。
  • LibreSSL修复了2.7.1版中的证书验证漏洞,由Python开发人员Christian Heimes发现,他也在Python本身中实现了一种解决方法
  • OpenSSL修复了两个漏洞,ASN.1解析器中的堆栈耗尽以及CRYPTO_memcmp函数的HP-UX / RISC汇编代码中存在的一个错误。
  • 研究人员发表了一篇论文,分析证书透明度日志中的证书与基准要求的一致性

稿源:Feisty Duck

IETF正式批准TLS1.3成为互联网新标准

互联网工程任务组(IETF)已正式批准TLS 1.3作为传输层安全协议(TLS)的下一个主要版本。

在经过了长达4年改了28次草案后,TLS1.3终于问世了!

它将成为客户端和服务器通过https连接建立加密通信的最新标准。

更好的加密 更少的延迟

相较前任版本,TLS 1.3有几个显著的优点。其最大的特点是使用了较新和难以破解的加密算法(ChaCha20,Poly1305,Ed25519,x25519和x448)来替代从前的MD5、SHA-224等。

其次在谈判客户端和服务器之间的初次握手时,TLS 1.3也快了不少,解决了多家公司因为延迟而坚持不支持HTTPS的顾虑。

第三,TLS 1.3还将支持TLS False Start和零往返时间(0-RTT)等功能,有助于缩短加密握手所需的时间。

第四,TLS 1.3具有防止降级攻击的功能。攻击者无法通过使用旧版协议的方式开展已知的漏洞攻击。

拒绝后门

TLS 1.3对互联网的安全性起到了很大的促进作用,在当今可称得上是几乎不可能破解。

在之前的报道中我们曾提及,金融部门成员要求在协议里引入后门,而IETF成员在最后依然拒绝了这一要求,一致通过了零后门协议。

金融部门的要求在提议之初就遭嘲讽,而今被打脸已成定局。

中间设备仍是难题

Chrome,Edge,Firefox和Pale Moon等浏览器已经推出了对早期版本TLS 1.3草案的支持,现在预计会将此支持更新为官方标准。

尽管浏览器厂商们将身先士卒实施TLS 1.3,该协议面临的主要难题还是那些旧的互联网中间设备。接收固件更新以支持新协议还得花费不少时间。

2017年12月进行的一项Cloudflare调查显示,TLS 1.3仅占互联网HTTPS流量的0.06%,而这种微不足道的市场份额的主要原因是许多中间商故意降级流量,因为他们无法支持它。

这些老旧的互联网中间设备也是2017年2月事件的核心。当时超过5万台Chromebook遇到各种问题,只因为谷歌在Chrome OS里率先使用TLS 1.3却遇上了屏幕闪烁、电脑变砖的尴尬。而最终,谷歌妥协,撤回TLS 1.3才让机器重新恢复正常运行。

 

稿源:bleeping computer

是谣言吗?花钱买来的证书比免费的更好?

目前我们看到网络加密的速度比历史上的任何时候都要快,我们正在取得令人惊叹的进展。知名安全博主Scott Helme每六个月都会发一份互联网排名前一百万站点的报告,在2018年2月最新的报告中,我们看到加密网站的迅猛增长:

谷歌也在去年公布了一组Chrome浏览器的数据:

全网加密成为一种趋势,并将最终成为所有网站的标配。

证书颁发机构起关键

一家CA(证书颁发机构)的作用是给您签发证书并安装到站点。证书在整个过程中起着至关重要的作用,即认证。 如果您在地址栏中输入sslchina.com,然后按回车,当页面加载时,您可以确定您已经从sslchina.com加载页面,并且没有人试图模仿我。 浏览器验证它收到的证书,以确保它是一个真正的证书而不是伪造的证书,证明它是由可信任的CA颁发的,并且该证书是发给sslchina.com的。 这是浏览器在建立安全连接时执行的第一步,如果失败,则不会再有任何事情发生。 然而,这是证书的全部。 一旦浏览器在连接开始时完成了这些检查,证书就可以被丢弃,不再有其他用途。

免费(DV)证书和收费(DV)证书的差别

一场关于DV证书的有趣争议正因为Let's Encrypt的存在进行着。CA曾以高价售卖DV证书赚得盆满钵满,直到两年前Let's Encrypt的横空出世打破了这一行业规则。免费证书无疑是诱人的,Let's Encrypt不得不面对来自行业、各界的质疑,但这与证书的质量有关吗?

所有由CA签发的证书都必须遵守CAB论坛制定的行业基准。这个文档事无巨细,从CA必须验证域名所有者到一张证书能用多久,各种颁发证书的限制都囊括其中。无论证书是不是收费,要求都一样。

除了控制证书颁发过程和策略的CAB论坛制定的行业要求之外,我们也必须考虑这些标准: 所有的X.509证书都必须按照规范签发,否则他们根本就不会工作! RFC 5280提供了所有颁发的证书必须符合的X.509v3证书配置文件。 这些标准同样没有提及证书是否收费或免费发放。

更好的加密

经常会有人说,证书多少会对通过连接传输的数据的加密产生影响。

这明显是谣言。真相是,证书与您传输的数据的加密毫无关系。但这种误解从何而来呢?逛一圈CA网站你就懂了:

数据的加密由服务器配置处理,而不是证书。 让我们来看看几个密码套件来证明这一点。 假设我们有一个2048位的RSA密钥,并且我们获得了一个证书,那么您将看到一个在生产中看起来像这样的密码套件。

TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
  • TLS - 正在使用的协议。
  • ECHDE - 椭圆曲线Diffie-Hellman短暂密钥交换,支持前向保密。
  • RSA - 用于认证的密钥,在这种情况下是我们的2,048位RSA密钥。
  • AES - 高级加密标准,用于加密数据的对称加密算法。
  • 128 - 对称密钥大小。
  • GCM - 伽罗瓦/计数器模式,我们使用认证加密(AEAD)。
  • SHA256 - 用于完整性检查的消息认证码。

证书唯一涉及的组件是用于身份验证的密钥。 在上面的例子中,我们使用了2,048位的RSA密钥,但我们甚至没有列出密码套件中密钥的大小,只是关键算法。 上面的特定密码套件使用128位密钥的AES,但如果我们想用256位密钥将其增加到AES,我们只需将配置更改为使用其他套件。

TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA256

现在我们使用256位加密,并且我们没有更改任何与证书有关的事情,我们仍然可以使用完全相同的证书。 事实上,不同的客户可能会根据其功能谈判这两个密码套件中的任何一个。 我们甚至可以更改身份验证密钥并获得ECDSA证书,但它们与加密无关,仅仅是再次更新密码套件。

TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA256

谈论购买或获取证书时可以使用的加密强度有点像谈论您的网站在购买或获取证书时是否具有响应式设计。 它与CA或证书无关,完全取决于现场进行配置和控制。

商业证书也提供免费证书

这是一个有趣的转折,当“商业CA”提供免费证书时我们做什么? 他们的免费赠品是否比他们的付费证书更糟糕,或者是商业CA的免费证书,因为他们是商业CA? 可能最大和最广为人知的免费证书来源是Let's Encrypt,但他们不是唯一一个发放免费证书的CA,也不是第一个。

早在Let's Encrypt存在之前,StartCom就发布了免费的DV证书,但这家CA已经关门了,不能再使用。 还有Comodo,提供90个免费证书,跟Let's Encrypt一样。

对信息加密没有任何影响,不仅免费证书和付费证书完全相同,连签发的架构都是一样的(出自同一根证书)。除了Comodo,AlwaysOnSSL也是一家免费、自动化的CA,还有一些主流CDN如Cloudflare也提供免费证书服务。当您注册Cloudflare并让他们代理您的流量时,他们会颁发证书通过其通用SSL程序安全地执行此操作。

鉴于Cloudflare可能是世界上最大的CDN提供商之一,为一些相当大的网站提供流量代理服务,人们对于Cloudflare发放的免费证书是略有微词的。因为它即没有保修期也没有保险。

免费CA不会对你增加额外限制

当你以为自己花钱买了张证书就万事大吉的时候,现实常常不那么如意。或许你现在只有两个服务器,但当你的站点扩张到需要3个甚至30个服务器时,你的CA会跳出来说让你加钱。而这其实和技术无关。纯粹是商业CA的加戏行为。免费CA就不会如此。

免费证书就是坑...吗?

要看你问谁了。商业CA或经销商估计会告诉你别用免费的。(毕竟除了他们家,在座的都是垃圾)但理智选择是很有必要的,明确自己的需求才不会被戏精坑。

证书具有二进制状态?

当您查看证书时,我们唯一真正关心的是浏览器是否会接受它,我们关心证书是否有效。 为了有效,上面列出了各种技术标准,包括它的格式,它包含的字段以及它们中必须满足的数据。 还有关于CA如何发布的标准,以及所有这些都对浏览器对证书本身的最终决定起作用。从微观角度来说,无论你交了多少血汗钱买证书都不会影响一个bit。一张证书是否免费与数据无关。

 

稿源:Scott Helme

为什么我们需要做更多的工作来减少证书的生命周期

本文由Scott Helme发布在个人安全博客中,原文请戳此处

在互联网加密的早期,你可以获得任意有效期的证书。那些日子已经一去不复返了,随着时间的流逝,我们才意识到我们需要做更多的工作来大大降低证书的最长有效期,这样做有很多不同的原因。下面就让我们来看看这些原因具体是什么。

证书有效期的历史

最初,证书颁发机构在它所颁发的证书的有效期上是不受任何限制的。在2000年代的时候,GoDaddy会很愉快地颁发给你一份有效期为10年的证书!想象一下,不需要更新,不需要处理,也不需要艰苦地工作。你只需要安装好这份证书,然后在将近十年的时间内,你都可以忘掉它了!有很多这样的例子,所以我从Censys中找了几个。你可以去这里这里还有这里看一看这些例子。如果你想看看完整的搜索记录以及更多的例子,你可以在这里找到它们。虽然看起来这似乎是个不错的主意,但实际上情况并不是这样,其中有很多原因,我将会深入讨论,但首先,我想让大家了解一下我们目前在证书有效期方面的基本立场。

对证书的最长有效期的第一个限制是出现了证书颁发机构/浏览器论坛(CAB论坛)以及他们提出的的“基准需求”文档。这个论坛通常被称为“CAB论坛”,它是对证书颁发机构如何按照“基准需求”(BR)中的规则颁发和管理公开可信证书的行为进行管理的机构。如果我们回过头来看看第一版的BR(它是在2011年11月22日被讨论通过并在2012年7月1日生效的),我们可以看到这一限制是如何被引入的。这一最早版本的文档的第9.4部分是这样表述的:

本文档生效后颁发的证书,有效期不得超过60个月。

这是对证书颁发机构的第一个限制,但即使是有效期为5年的证书也不会长期存在。为了让GoDaddy开心,引入了5年的限制,但很快就被降低到了39个月。

除下列情形外,2015年4月1日以后颁发的证书有效期不得超过39个月。

自从第一个版本的BR发布以来,已经有3年时间了,5年的最长证书有效期已经被降至3年多一点。2015年4月1日以来,我们的证书的最长有效期一直是39个月,而在最近,我们正努力将证书的最长有效期进一步缩短。

目前的证书有效期

在2017年2月,CAB论坛针对谷歌的Ryan Sleevi提出的一项议案进行了投票,将证书的最长有效期缩短至仅398天,这是网络安全方面的巨大进步。遗憾的是,这次投票并没有通过,而且遭到了广泛的反对,在所有参加投票的证书颁发机构中,只有一家投票赞成。以下是投票情况:

证书颁发机构的投票情况——共计25票(不包括弃权票)

1票赞成:Let’s Encrypt

24票反对:DigiCert, Entrust, AS Sertifitseerimiskeskus, Izenpe, ANF Autoridad de Certificación, Comodo, Certinomis, HARICA, GlobalSign, Quo Vadis, GoDaddy, Actalis, Symantec, Trustwave, CFCA, Secom, TWCA, GDCA, Certum, OATI, Buypass, SHECA, CNNIC, Cisco

3票弃权:Logius PKI, SwissSign, Chunghwa Telecom

浏览器厂商的投票情况——共计4票(不包括弃权票)

2票赞成:谷歌、Mozilla

2票反对:微软、奇虎360

1票弃权:苹果

鉴于投票未能将证书最长有效期缩短至398天,有关方面又于2017年3月提出了一项新的议案,该议案试图将证书最长有效期限制在825天以内。这次议案获得了通过,投票情况如下:

证书颁发机构的投票情况——共计27票(包括弃权票)

24票赞成:Entrust Datacard, TurkTrust, Izenpe, Certinomis, DigiCert, Amazon, CNNIC, HARICA, GlobalSign, GDCA, Disig, Trustwave, Let’s Encrypt, Quo Vadis, SHECA, CFCA, OATI, Comodo, Buypass, Logius PKIoverheid, Cisco, Symantec, Certum, SwissSign

0票反对:

3票弃权:ANF Autoridad de Certificación, Secom, Actalis

浏览器厂商的投票情况——共计6票(包括弃权票)

5票赞成:苹果、奇虎360、微软、Opera、谷歌

0票反对:

1票弃权:Mozilla

这意味着,从2018年3月起,所有新颁发的证书的最长有效期将被限制在825天以内!这是更大范围内网络安全的一大进步,我希望今年晚些时候再进行一次投票,争取将证书最长有效期再次缩短到398天。也许这次将证书最长有效期限制到825天的小小进步将足以鼓励我们下一步的努力,但我们现在只能等待和观望了。如前所述,我们已经清楚地表明了我们在证书有效期问题上的立场和观点,那么现在就让我们来看看,为什么我们需要缩短证书有效期,这么做到底能带来哪些好处。

为什么我们需要更短的证书有效期

乍一看,似乎更短的证书有效期会带来痛苦,人们不得不更加频繁地更新它们,但实际上,缩短证书的寿命会在安全方面给你带来很大的好处。

证书撤销机制已被破解

你可以通过证书撤销来阻止攻击者在窃取你的私钥之后使用你的证书。如果我能够窃取域名paypal.com的私钥,或者他们像无人机制造商大疆(DJI)最近所做的那样不小心把私钥发布到了GitHub上,那么我现在就可以使用这个证书来证明我就是paypal.com,可以拦截/解密该域的网络通信,并且还能在用户的浏览器地址栏中显示绿色的https标识。这是一个非常糟糕的情况,我们需要一种机制来阻止这种情况发生,这个机制就是证书撤销。然而不幸的是,证书撤销机制被破解了。我们所说的破解不仅仅是受到了一点点损坏,你可以去读一读我刚才给出的链接中的文章,该机制已经被完全破解了。在我假设的我窃取paypal.com证书的私钥的例子中,PayPal基本上没有任何手段阻止我使用他们的证书。为了保护自己和客户,他们唯一能够采取的真正的防御措施是,获取有效期较短的证书。

想象一下有效期分别为3年和3个月的证书之间的区别。假如,在你获得了崭新的证书之后1个月,我设法攻击并窃取了你的私钥。如果你的证书有效期是3年,那么我现在有2年11个月的时间来盗用这个证书,并且会带来损害。这样,访问者可以访问paypal.com,并在地址栏看到绿色https标识,这种情况会持续2年11个月,用户甚至可能完全无法和真正的PayPal进行交流,也不会有安全连接。这很不好。现在考虑一下有效期为3个月的证书。如果在你获得它的1个月后,我窃取了你的私钥,那么作为攻击者,在证书过期之前,我只有两个月的时间来盗用它。这会迫使我更快采取行动,我现在拥有的行动时间变短了,总体上看,你的用户面临的风险将会大大降低。

冲刷生态系统

正如你在任何复杂的生态系统中所可能看到的那样,在更广泛的证书生态系统中,情况已经发生了一些变化。新的字段被引入到证书中,旧的字段被弃用,可接受的值也发生了变化,特别是在与加密有关的时候,我们必须不断地适应新的威胁和更为强大的对手。在这方面有一些很好的例子,证书的最长有效期是一个关注点,最近的例子就是SHA-1的弃用。

证书颁发机构过去经常使用SHA-1散列算法来生成证书上的签名。这种签名赋予证书所有的值,浏览器通过签名来验证证书是否来自可信任的证书颁发机构,以及是否被篡改。而问题在于,SHA-1算法越来越老旧,越来越脆弱,而最终,它将会不可避免地被破解。在2014年10月的CAB论坛118号投票中,论坛决定,从2016年1月1日起,不允许任何证书颁发机构颁发由SHA-1和SHA-256算法签名的证书。这很好,我们有了截止日期,但问题在于,在停止接受SHA-1算法签名的证书之前,浏览器不会等待很长时间的。Chrome宣布,从2017年1月1日起,他们将停止接受SHA-1签名的证书,其他浏览器厂商也随之采取了同样的做法。这也是一件好事,因为在那之后的几个月,SHA-1算法就被破解了

这意味着,你可以在2015年12月31日获得一个有效期长达39个月的证书,该证书在2019年3月之前一直有效,而这种情况在2017年1月以后就不会出现了。但是,这39个月的有效期还是太长了,以致于整个行业没有足够的时间来应对新的攻击行为,这意味着网站会一直拥有有效的证书,直到这些证书过期。

SHA-1算法被弃用这样的情况并不是第一次出现,而且肯定也不会是最后一次。我们还看到了其他的一些变化,比如从1024位RSA密钥到2048位RSA密钥的转变,以及最近Chrome浏览器对常用名称字段的弃用,他们要求网站在证书过期之前重新颁发。作为一个更广泛的行业,不断有新的威胁出现,需要我们应对,所以39个月的时间太长了,我们必须能够在更短的时间内将所有现有证书的生态系统冲洗一遍。

密钥更换

证书的过期提供了一个很好的机会来更换与该证书一起使用的密钥。除了过期证书的自然更新之外,如果你想要更换密钥,就必须重新颁发证书,而这是不太不可能的。除了HTTP公钥绑定(我最近已经放弃使用它了,Chrome浏览器也宣布了弃用它)之外,你应该至少每年都要更换一次你的私钥。而当证书最长有效期是39个月或者是825天的时候,大多数密钥更换周期实际上都会达到这一时间上限,而不会比这个时间短。这是一种糟糕的卫生习惯,而且一种密钥的使用时间越长,它就越有可能面临安全风险,只要有可能,我希望看到尽可能短期的密钥,而不希望看到静态的密钥。

证书透明日志不合格

虽然这并不是迫在眉睫的问题,但是,我们看到,Chrome浏览器提出了一项新的要求,即所有证书都需要在证书透明方面合格,因此在接下来的几个月里,它将成为非常值得考虑的事情。证书透明是一个非常棒的新要求,应该会在2018年4月实现,这将要求所有证书颁发机构将它们颁发的所有证书记录到公开日志中,这些日志可以接受审查。这意味着,任何证书颁发机构的业务对我们来说都将有充分的透明度(这些超级强大的机构实际上是网络加密通信的守护者),这样,就没有人能够在你不知情的情况下获得你的域的证书。要通过证书透明系统的检查,一份证书必须包含

来自3个独立日志中的至少3个签名证书时间戳(SCT)。如果一个证书不包含3个有效的SCT,那么它就不会通过证书透明系统的检查,而浏览器则会拒绝它。如果证书日志在证书的有效期内被取消资格,那么从该日志开始,该证书内的SCT将会失效,从而使证书不再满足证书透明系统的要求。

现在,为了应对这一机制,一个证书颁发机构可以通过在证书中放置多个SCT来提供保护,以避免被证书透明系统取消资格,但是问题仍然存在。证书的有效期越长,就越有可能出现日志不合格的情况,那将会使证书无法通过检查,从而被证书透明系统拒绝。较短的证书有效期有助于防止出现这一问题,而且相对于有效期825天的证书,在有效期90天的证书中包含较少的SCT也安全多了,同时证书也会更小。

因为熟能生巧

想象一下,你每5年只做一次任务,你觉得你还会记得那些步骤吗?你在2013年做的事情在你的脑海里会是新鲜的还是模糊的?我最近看到的一件事就是一些大网站提供了过期的证书。

现在我确信,经常会有一些真正的错误和疏忽,但是我听说过很多公司的故事,他们只是忘记了。有人买了一个证书,该证书会在3年多以后失效,这是一个很遥远的日子,然后它就被遗忘了。不仅如此,当需要进行更新时,没有人记得整个操作过程、谁做的、他们是怎么做的或者文档在哪里。让证书更新成为一个常规过程的一部分,它们很快就会成为你所做的那些甚至不需要“思考”的任务之一。但是,你知道还有什么比这更好的吗?那就是自动化。

自动证书更新

关于Let’s Encrypt让我非常喜欢的一件事并不是他们是一家免费的证书颁发机构,而是他们的证书更新过程可以是完全自动的。不要误解我的意思,降低成本对很多人来说是件大事,但我已经很乐意为证书付费了。对我来说,关于Let's Encrypt的好处,更加重要但又较少被谈到的一件事是,你怎样才能获得证书。我(博主)对Let's Encrypt曾经讨论过很多,如我的入门指南、我的非常酷的带表情的子域🔒🔒🔒.scotthelme.co.ukECDSA certificates、我的智能更新脚本以及更多

尽管我所做的所有关于Let's Encrypt的事情都很酷,但我要说,其中最好的一件事绝对是,通过使用一个简单的cron 作业,我就可以自动更新我所有的证书,而没有任何事情需要担心。

见鬼,我甚至是在我的Ubiquiti家庭网络设备上操作的!Let's Encrypt只颁发有效期为90天的证书,如果你想要手动更新的话,那将是一个很大的问题。我们想要频繁的更新,但是当你获得更多的证书时,手动的操作就变得更加困难了,这就是自动更新变得必不可少并且我还要继续向那些听我讲话和接受我培训的每一个人推广自动更新的原因。可以消除错过更新的风险,可以消除人为错误的风险,还可以降低获取和更新证书所涉及的成本。为什么不喜欢它呢?我意识到,现在它可能并不是一个对每个人来说都切实可行的选择,但是自动更新的整体概念对几乎所有人来说都是全新的。随着时间的推移,这只会变得越来越好。今后将会有更多的工具、更多的服务和更多的产品在这方面为你提供帮助,所以,也许不是今天或者下周,但这肯定会很快发生的。

当你的证书颁发机构太任性的时候怎么办

诚然,这是一个小得多的问题,但仍有可能发生。现在,我们看到了对Symantec公司作为一个证书颁发机构的更广泛的不信任,而网站不得不在其证书到期之前进行更换。你可以很容易地从Symantec公司得到一份有效期为39个月的证书,但该证书在你购买后不到一年就会停止工作。如果替换证书是你的工作中的一个常规部分,而不是每3年才会去做的一些奇怪的步骤,那么更换证书就会容易得多。

我们正朝着正确的方向前进

我们确实是在朝着正确的方向前进,我很高兴看到我们不仅在加密整个互联网,而且在证书有效期的缩短方面都取得了进展。随着我们在整个互联网上颁发越来越多的证书,网上的问题只会越来越与更多的站点有关。如果你想要开始把HTTPS部署到你的网站上,那么现在就是这么做的最好时机。选择有效期短的证书,尽可能多地考虑自动化过程,这样可以帮你更好地入门。如果你使用https已经有很长时间了,可能你用的是有效期为39个月的证书,也许现在是时候考虑用更新、更快、更简单、更便宜的方式来替换旧的证书更新过程了。我们需要继续让互联网加速向https转变,并继续缩短证书的最长有效期,但这并不意味着你必须获得具有最长有效期的证书,你也可以选择有效期更短的证书。

EV证书

这里的另一个观点是,你可能会遇到EV证书的问题——EV证书真有学术论文说得那么好么?答案是:不。EV证书本质上与上面列出的几乎所有观点相违背。EV证书很难获得,获得它需要有一个漫长的过程,所以人们想要尽量避免这样做。这迫使人们为他们的证书上选择更长的有效期,以避免这种艰难的过程。人们越来越倾向于选择更长有效期的证书,这不是我们希望看到的。不仅如此,证书颁发机构还通过打折促销手段来积极鼓励人们购买更长有效期的证书,所以网站又也有了财务方面的动机去做错误的事情。

EV证书的另一个问题是,它是反自动化的。获得一个EV证书需要人工操作过程,再加上完成这一过程需要数小时甚至数天,这意味着没有办法自动完成。你将不得不继续手动地获取和管理这些证书,这花费太多精力了。如果你需要在被攻击后快速更换你的密钥和证书,这对你也是不利的。总的来说,我们将继续推动密码有效期变得更短,由于很好的理由,短期密钥更受欢迎,而我们越努力地降低证书的预期寿命,情况就会越好。

Chrome 66 Beta即将上线 你的赛门铁克SSL证书可能会停止工作

Google Chrome 66 Beta将于3月15日,即本周四发布。

虽然谷歌和赛门铁克之间的冲突在去年夏天或多或少得到了解决,但这些决策的影响仍将有所体现。

尽管DigiCert和赛门铁克一直在努力让客户迁移到DigiCert PKI,但Google Chrome(以及Mozilla Firefox和其他浏览器)不信任现有的Symantec SSL证书的截止日期已经到来。 考虑周四是该截止日期的最终前兆,因为任何在2016年6月1日之前发布的Symantec SSL证书都会因Chrome Beta用户而破裂。

Chrome 66已经发布到Canary和Dev频道,这意味着受影响的网站已经在影响这些Chrome频道的用户。 如果受影响的网站在2018年3月15日之前不替换其证书,则Chrome Beta用户也将开始遇到此类问题。 如果您的网站目前在Chrome Canary中显示错误,强烈建议您尽快更换您的证书。

这包括所有Symantec CA品牌(包括Symantec,GeoTrust,Thawte和RapidSSL)。 到了2018年4月17日,谷歌浏览器66将成为稳定版本。

google chrome symantec ssl certificate warning

如果你的网站在浏览时出现这个状况,请马上联系你的SSL供应商。

Chrome 70: 停止信任的终点

7月20日左右,Chrome 70将有稳定版本。 此时,所有Symantec SSL证书都将停止工作。 如果您的SSL证书尚未于2017年12月1日或之后从DigiCert的根源颁发,则从Chrome 70开始无法使用SSL证书。相反,您的网站将收到安全警告。

这是赛门铁克SSL证书最后的不信任期限,赛门铁克,GeoTrust,Thawte,RapidSSL和Verisign根证书将于7月20日正式下线。

所以,换证书的事儿你都准备好了吗?