关注网络安全
和行业未来

LinkedIn的SSL/TLS证书再次过期

这是领英两年来第二次遭遇证书过期。

LinkedIn再次强调了良好的证书管理的重要性。SSL/TLS证书在两年内第二次过期,导致该社交媒体站点停机。这次的罪魁祸首是LinkedIn的链接缩短器,lnkd.in。5月21日星期二,桌面用户开始看到那些可怕的SSL连接错误消息。

LinkedIn匆忙地修复了这个问题,迅速安装了一个新的SSL/TLS证书,但它也作为一个教训,给我们上了一课。

所以,今天我们将讨论到底发生了什么,为什么它会再次发生,以及我们本可以做些什么来防止它。

证书过期再次出现!

鉴于这是两年来第二次发生证书过期得情况,你不得不怀疑LinkedIn是否吸取了第一次的教训。证书过期轻易地成为了LinkedIn最近发生的第二糟糕的事情。最糟糕的是它的视频添加。证书过期带来的麻烦不仅仅是停机那么简单,它最终都会导致花费大量的资金。

实际上花费了多少,LinkedIn也很难算清楚。这次宕机的影响只波及到试图使用该公司链接缩短器的桌面用户。LinkedIn现在属于微软,微软不太可能给出具体数字:有多少用户无法连接、或这次中断具体持续了多久;并且2018年,LinkedIn的收入高达53亿美元,所以即使停机所带来的损失达到数百万,也没人会觉得这是什么很令人惊讶的事情。

对于规模较小的公司来说,停机是一个很大的问题,LinkedIn可以轻松应对停机成本。对于像LinkedIn这样规模的公司来说,停机所带来的品牌损害才是最大的问题。有些用户永远也不会知道,或者看到也不知道该怎么做,更精通技术的用户可能会开始形成关于LinkedIn如何认真对待安全问题的批评意见。

如果使用好的证书管理工具,这是一个可预防的问题。短短两年内,证书过期已经出现了两次。这也不是LinkedIn遇到的唯一与安全相关的问题。随着时间的推移,所有的安全问题累积在一起,考虑到人们在领英分享的一些信息相当敏感,失去信任对LinkedIn来说可能是灾难性的。

究竟发生了什么?

要理解到底发生了什么,你需要先快速了解链接缩短原理以及公司使用它的真正原因。这的确是一个很巧妙地方式,将链接插入到限制字符个数的社交媒体帖子中,就像Twitter不将URLs作为字符计算一样,但这样做的真正原因是为了分析。公司需要跟踪谁点击了他们的内容,是人还是机器人,他们来自哪里,等等。

所以,当你使用链接缩短器时,它有点像在连接的中间放了一个代理。链接连接到链接缩短域,该域检查流量并将其重定向到预期的地址。为了实现这一点,需要发生两个不同的连接,因此需要两个不同的SSL证书。链接缩短域需要一个,然后实际的网站本身也需要一个。

在本例中,SSL/TLS证书保护链接缩短域lnkd.in。证书一旦过期,任何试图单击缩短链接的人都无法连接。

这似乎是可以预防的。
证书过期会产生相当大的风险,LinkedIn再次表明,只要一个证书过期就可以影响很多客户的操作,如果它发生在足够敏感的地方,后果不堪设想,是时候在证书管理上多下功夫了!您需要一个可视化工具来管理证书并保持可见性,您需要一个便捷的工具协助您管理证书生命周期的每个阶段:发布、轮换、续订、撤销等,例如,KeyManager,提供安全便捷的证书管理服务,守护您的资产和品牌声誉!

文章来源:hashedout

Alphabet的Chronicle子公司对无管制环境下代码签名滥用进行了探究

一项新的分析着重指出了由证书颁发机构签名的恶意软件的泛滥,和基于信任的安全问题。

Chronicle(Alphabet的子公司,是一家网络安全公司)的研究人员发布了一份分析报告,关于无管制环境下利用已签名的恶意软件趋势的调查分析。

对代码加密地签名的过程是为了让Windows操作系统能够区分安全代码和恶意代码。证书由受信任的证书颁发机构(CA)签署/签发,并由受信任的根CA支持。签名Windows可执行文件的目的是为了对发布在Internet上代码的真实可靠性进行认证。

问题是,受信任的系统,正在被网络罪犯利用。

恶意软件发布者通过经销商或直接购买证书。CA可以撤销被认为不可信的证书(许多确实是不可信的),这仍被认为是减少滥用的唯一方法,但它没法阻止恶意软件拥有可信的证书。

为了特别强调这一趋势的泛滥程度和基于信任的安全问题,Chronicle的研究人员通过一种在线病毒/恶意软件扫描器, VirusTotal,分析系统杀毒工具可能漏掉的可疑文件。他们将此项目限制在Windows PE可执行文件中,过滤掉少于15个聚合检测的样本,并“积极地”过滤掉了灰色软件文件,确定了每个CA负责签名的恶意软件样本的数量。当所有这些都被过滤掉后,研究人员最终得到了3815个恶意软件样本。

Chronicle指出, VirusTotal检测到的已签名恶意软件中,签署了超过100份证书的CA占了78%。有趣的是,对于签名的恶意软件样本数量,CA之间的差异显著。例如,COMODO RSA代码签名CA的样本最多,为1775个,几乎是Thawte SHA256代码签名CA的3.5倍,后者的数量仅次于前者,为509个恶意软件样本。数字从Thawte SHA256代码签名CA开始继续下降;第三个CA签名的恶意软件样本数量为Thawte SHA256代码签名CA的一半。

研究人员报告指出,CAs正在对抗这一趋势。超过20%的恶意软件在Chronicle博客文章发表时被吊销了证书,这表明CAs正在打击恶意软件。

正如Chronicle所指出的,攻击者利用用户的信任已不是什么新鲜事,它一度被认为主要在民族国家攻击者中流行。现在,这一趋势似乎已经成为大多数携有恶意软件的网络罪犯的普遍做法。

文章来源:Dark Reading

代码签名证书过期,Mozilla数百万Firefox用户遭遇扩展禁用

5月4日(GMT)早上,Mozilla的Firefox用户怨声载道,大量用户打开浏览其发现扩展插件无法使用,手机版也是如此。有报道称,此现象是由于Firefox底层SSL根证书过期所导致的,但据我们了解,这是由于AMO使用的代码签名证书无效所导致的,Firefox私有中间证书过期致使代码签名证书无效,从而导致插件验证无法通过。Mozilla Add-ons,也称为AMO,是一个为Mozilla产品查找和安装Add-ons的资源,用于签名和验证插件。

下图所示为AMO证书链,签名证书(也称为end-entity证书)由Firefox私有PKI的一个中间证书颁发,且为每个插件都签发有单独的签名证书。国际CA的中间证书有效期一般为5~10,而Firefox的只有2,首先2年的证书有效期很容易被人忽略,其次对于证书到期Firefox却无感知,可见Firefox在管理证书方面非常不严谨,不禁令用户担忧用于插件的代码签名私钥的安全问题。证书到期现象多发生在用户的HTTPS站点上,建议大家使用专业的证书管理工具,例如KeyManager.orgMySSL.com的证书到期提醒服务。

下图为Firefox私有中间证书,红框所示为中间证书到期日。

证书过期导致:

1.插件无法安装。

2.已经安装的插件无法使用

 

早先的 Firefox 没有强制必须通过 AMO 签名插件,用户可以自行选择代码签名证书,并且分发渠道分散,导致生态内部安全风险比较高。但现在政策调整为:正式版、beta版的安装插件必须被AMO签名,Nightly和Developer Edition可以加载未签名的插件。

扩展/插件签名的官方说明:Add-ons/Extension Signing

提交插件到AMO签名的官方说明:签名和分发你的扩展

 

是否想过,遭遇钓鱼攻击的你可能会有生命危险?

Triton恶意软件的设计意图是“明目张胆地伤害人们”

91%的网络攻击始于电子邮件。令人担忧的统计数字,但人们并没有清楚的意识到其中的利害关系。对许多人来说,遭遇钓鱼攻击可能就只是意味着个人的尴尬处境,也可能是经济上的损失, 毕竟没有危及到生命。不是吗?

然而并非如此。在过去的一年半里,研究人员一直在追踪一种名为“Triton”(有时也称为“Trisis”)的新型恶意软件,该软件能够关闭工业安全仪器系统。这些系统是由物理控制器及相关软件组成,用于预防工业环境中可能发生的危及生命的各种灾难。

2017年夏天,沙特阿拉伯的一家石化工厂因为压力释放装置和关闭阀等部件失灵险些发生灾难,这算是最初与Triton相关的事故了。仅仅因为代码中的一个小小的错误,在工厂工作的人、以及那些不幸生活在周围地区的人们,差点儿受伤甚至死亡。

攻击者很可能在某一刻使用过鱼叉式网络钓鱼来窃取密钥凭据,使他们能够直接访问安全仪表系统。

所以,今天我们将讨论Triton,杀手网络钓鱼软件,以及如何保护你所在机构的电子邮件。

那我们来开始讨论吧。

什么是Triton恶意软件?

Triton恶意软件是一种专门针对工业安全系统的恶意软件,其目的是要引起灾难。它的首次“亮相”(找不到更好的词汇来表达它了)是在2017年针对一家未具名的沙特化学公司进行了攻击,上文提到过。时至今日,这家公司的名字还没有披露。这样做是为了让其他公司可以报告此类攻击。

Triton因其代码中的一个小缺陷而变得有残缺,该缺陷使工厂及时停工,在可能造成任何人身伤害之前提醒该公司注意到了此次攻击。此次事件发生在2017年6月。当时,这被认为只是一个简单的机械故障。但今年8月,该工厂再次停工,这一次,该公司引入调查人员进行了调查。

[朱利安]古特马尼斯回忆说,在石化工厂处理恶意软件是一件伤脑筋的事情,而这家工厂在经历第二次事故后已重新开工。“我们知道我们不能依赖安全系统的完整性,”他说。“这真的是最糟糕的情况了。”

此次攻击直到当年12月才被公开披露,自从发现该恶意软件以来,安全公司和研究人员一直在努力破解它,搞清楚它是如何工作的。

这个恶意软件之所以可怕,是因为它会造成真正的伤害。它不同于劫持某人的文件以勒索赎金或者窃取个人信息,它可能会杀死某个人。

它是非常复杂的。

是什么让Triton恶意软件如此复杂?

首先,Triton背后的人拥有可供他们支配使用的的大量资源,再加上一些高级技术已被串联在一起这一情况,研究人员认为他们背后是一个民族国家。但究竟是哪一个国家呢?这仍然是一个争论点。虽然最初被认为是伊朗,但现在,FireEye(一家美国网络安全公司)将责任归咎于俄罗斯。

不管幕后黑手是谁,这都是这一趋势的一部分,受政府支持的网络攻击者将私营企业作为目标的趋势。去年的Marriott数据泄露就是活生生的另一个例子。

这次攻击实际上开始于2014年,当时攻击者进入了这家工厂运营商的企业网络。某种程度上讲,他们获得了目标工厂网络的访问权,然后,使用可能是通过鱼叉式网络钓鱼获得的凭证,攻击者得到了对工程工作站的访问权。

该工程工作站直接与工厂的安全仪表系统对接,于是该系统向攻击者“透漏”了所使用的制造商和型号及其固件版本。它们在网络中的持久性使攻击者对系统的任何更新都保持可见。

攻击者最终将目标锁定在了Schneider Electric的安全仪器设备,Triconex安全控制器,Triton恶意软件的名称即由此得来。据《MIT Technology Review》报道,在部署该恶意软件之前,为了对其进行测试,攻击者很可能购买了一台Schneider Triconex设备,协助他们编写能够避开恶意软件扫描和其他安全保障措施的代码。

真正“助力”此次攻击的是在Triconex安全控制器中发现了一个新的Zero-day(零日漏洞或零时差漏洞),这进一步增加了Triton成功的机会。

结果是,入侵者持续存在于网络中,注入代码,命令安全设备自行关闭,就像其它恶意软件对工厂造成的严重破坏一样,造成可能非常致命的局面。

“一旦成功,结果可能是可怕的。迄今为止世界上最严重的工业灾难还包括有毒气体泄漏。1984年12月,印度博帕尔的Union Carbide农药厂释放出大量有毒烟雾,造成数千人死亡,更多人严重受伤。造成这种情况的原因是维护不善和人为失误。但该工厂出故障无法运行的安全系统导致最后一道安全防线崩溃了。”

首先,电子邮件安全从来没有像现在这样重要

让我们先从电子邮件安全开始。虽然目前还不能确定这些被盗的工程凭据是通过鱼叉式网络钓鱼获得的,但有报道称确实如此。尽管也有其他方法能够访问终端,但鱼叉式网络钓鱼似乎是最有可能的罪魁祸首。

鱼叉式网络钓鱼的基本原理是网络钓鱼+社会工程。攻击者会针对目标进行一些研究,通常会借助LinkedIn这样的网站,营造一个令人信服的场景,从而获得目标信息。这种类型的网络钓鱼通常都会有一个令人信服的虚假网站,配置了HTTPS安全指示,旨在获取目标信息。

这强调了恰当的网络安全的重要性。考虑到攻击者在网络中的存在,他们很有可能从可信的电子邮件服务器发送一封令人信服的电子邮件,愚弄SPFDKIM。但S/MIME和电子邮件签名能够防止这种情况的发生。

教员工签名电子邮件和识别电子邮件上的签名,并对他们进行有关电子邮件安全最佳实践方面的教育,对于保持良好的企业安全态势至关重要。你的员工,不管他们的意图如何,都是你最大的威胁。

一本关于电子邮件安全最佳实践的电子书即将会推出。它包括36页的策略和见解,旨在保护组织的电子邮件免受现代企业面临的最危险的威胁。请予以关注。

第二,物联网安全不容忽视

尽管这已经说了很多遍,写了多少遍,现在已经让人厌烦了,但仍有必要重复:保护物联网需要成为每个人(从制造商、供应商到最终用户)的优先事项。因为很可能是针对物联网设备或组件的某一攻击造成人员伤亡。

如果不是因为钓鱼程序的一个小故障,或者更恰当的说是一个疏忽,使工厂在紧急情况下关闭,那么这次网络攻击很有可能实现了那个不幸的里程碑。下次我们也许不会这么幸运了,这种情况已使得安全研究人员彻夜难眠了。

历史上,即使是最具破坏性的恶意软件,也从未试图伤害人类。

前美国海军信息战军官、现就职于Dragos(网络安全公司)的乔 · 斯洛维克(Joe Slowik)解释称:“从道义上讲,攻击安全系统似乎是一个禁区,在技术上也很难做到这一点。”

2010年的Stuxnet就是最著名的例子,它破坏了伊朗核计划的关键系统,导致离心机过热。俄罗斯政府曾使用复杂的恶意软件破坏多个国家的电网。它被命名为Crash Override,我觉得这是根据上世纪90年代的一部通俗电影《Hackers(骇客)》中的角色来命名的,这POODLE攻击更令人震惊。

不管怎样,这凸显了物联网安全的重要性。尽管新兴的互联互通很棒,但仍有一些固有的风险必须加以解决。在很大程度上,工业部门在确保自身安全方面做得相当不错。

工业企业通常通过一种“纵深防御”的战略抵御攻击者。这意味着要创建多个安全层,首先是防火墙,隔离企业网络与互联网。其它安全层用于防止黑客进入工厂网络接触工业控制系统。

这些防御措施还包括发现恶意软件的抗病毒工具,以及越来越多试图发现IT系统中的异常行为的人工智能软件。然后,作为最终的安全后盾,还有安全仪表系统和物理自动防故障装置。最关键的系统通常有多个物理备份,以防止任何一个组件发生故障。

但即使是最好的安全态势也可能被不负责任或疏忽大意的合作伙伴破坏。在这种情况下,攻击者的复杂性给他们带来了许多不受国家支持的黑客所没有的优势,但危害仍来自企业利用的第三方IoT(物联网)设备。这就是为什么我们将安全称为一个生态系统,因为可能不是您的错误导致您受到危害,而是您的错误可能会给他人带来危害。

原文稿链接:What if getting phished could kill you?

证书过期?私钥泄露?掌控您的证书和私钥,维护网站安全和声誉!

数字证书,作为网络世界的身份证,提供了一种在Internet上验证通信实体身份的方式,其作用类似于司机的驾驶执照或日常生活中的身份证。譬如,Web Server通过提供自己的数字证书来证明自己的身份,用户得以确认所访问的网站就是想要访问的网站,建立起通信双方的信任关系。数字证书应用除服务器证书外,还包括电子邮件证书,代码签名证书,文档签名证书等。保证证书的有效性对用户和企业来说都是至关重要的。

就在2018年12月22日,因美国政府关门导致许多 TLS 证书已经过期,证书无人续订,无人管理,这使得许多站点无法被公众访问。该问题还影响到了与.gov域相关的许多证书,用户无法完全访问这些站点。证书若不续签,我们可能会看到更多的政府网站出现问题。

在当代,证书管理已成为企业的主要负担。企业规模越大,管理问题就越严峻。对证书管理策略没有前瞻性会给您带来什么样的问题?

死亡五指

使用武侠风的标题,揭示证书管理不善会带来的五个噩梦场景:

  • 证书到期导致的服务意外中断
  • 糟糕的证书/密钥管理导致的审核失败或违规
  • 服务器证书和密钥泄露/滥用
  • 代码签名证书和密钥泄露/滥用
  •  CA泄露; 流氓CA,用于MITM或网络钓鱼(流氓证书)

这些都是当你的证书过期时会发生的事情,任何一个场景的发生都会带给您“可观”的成本。

场景 预测成本
证书到期导致的服务意外中断成本 $11,122,100
由于无文档或糟糕的密钥管理导致的审核失败/不合规的成本 $14,411,500
服务器证书和密钥滥用的成本 $13,423,250
代码签名证书和密钥滥用的成本 $15,025,150
CA泄露或用于MITM或网络钓鱼的流氓CA的成本 $13,219,850
总成本 $67,201,850

一切始于可见性

对于大多数组织而言,大规模证书管理的可见性是证书管理三大痛点之一。 他们不知道他们有多少证书和密钥,他们不知道是谁订购了证书,他们也不知道证书什么时候到期。有调查显示,该痛点比例为71%。

                                                         数字证书面临的最大挑战

许多组织表示他们没有足够的的IT安全人员来维护和保护密钥和证书,不知道IT安全需要管理多少密钥和证书,更不用说在整个生命周期内保护密钥和证书了

如何帮助企业避免证书管理的痛点?在它反噬之前,企业需要先一步的采取行动了。

优质的证书管理平台

通过投资优质的证书管理平台,可以避免证书管理的痛点。 一些供应商都有很好的相关产品,譬如KeyManager(官网地址:https://keymanager.org/),它扫描您的网络并管理所有发现的证书,提供证书可见性和管理证书生命周期所有阶段的界面。

证书管理给人的感觉是昂贵且复杂的, 但并非如此。 从长远来看,这不是一个沉没成本(已经付出且不可收回的成本),这是一项投资,因为证书管理不善的代价是更加惊人的。

文中提及的调查数据及结果来源于:71% of Organizations don’t know how many certificates & keys they have

您的SSL/TLS证书应该采用ECC加密算法了

RSA的日子已屈指可数了,相比RSA,ECC更轻、更快、更安全。

我们一直在谈论ECC,让我们诚实的讨论一下吧。ECC看起来有点抽象,这可能不利于提高它的采用率。目前发行的大多数SSL/TLS证书使用的都是RSA公钥加密。我们之所以知道是因为我们卖了很多。

据我所知,ECC的使用率低很大程度上归因于大众认为基于ECC的加密系统在用户的浏览器和操作系统上没有得到广泛支持。

然而,事实并非如此。

所以,我们将讨论对“ECC不被支持”的错误认为,然后我们将讨论ECC本身、它的优点,以及为什么应该在SSL/TLS证书中使用它。

让我们开始讨论吧!

所有现代的操作系统和浏览器都支持ECC

SSL/TLS行业一直受到不再适用的传统观点的束缚。从HTTPS速度较慢的观点,到网站不收集个人信息所以不需要SSL的谬论,无所不包。虽然在一段时期内所有这些观点都是真的(在一定程度上),但在当代情况大不一样了。

这其中就包括了ECC没有得到终端用户广泛支持的观点。

服务器对ECC的支持可能是不同的。以下是主流操作系统对ECC的具体支持情况:

操作系统 最低版本要求
Apple OS X OS X 10.6
Microsoft Windows Windows Vista
Red Hat Enterprise Linux 6.5
IOS IOS 7.x
Android OS 3.x
Microsoft Windows Phone 7.x

以下是4个最流行的浏览器兼容ECC的情况:

浏览器 最低版本要求
Apple Safari 4
Google Chrome 1.0
Microsoft Internet Explorer 7
Mozilla Firefox 2.0

的确,Windows XP 用户和古董级设备可能无法兼顾对ECC的支持,这就完美的过渡到我们下一个观点。

高瞻远瞩,不要留恋过去—不要把互操作性置于安全性之上。

RSA已时日不多,在过去的两个月里,我们详细介绍了针对RSA和许多过时的SSL/TLS部署的漏洞。共同的认知是,打着互操作性的名义继续支持老旧的、脆弱的加密系统和算法,会给企业招致不必要的风险。

相信我,我充分理解为什么需要互操作性。企业不愿将任何人拒之门外。但是,如果你继续遵循此想法,你就会错失享有ECC具有的几大优势。

  • ECC密钥更短,意味着ECC将占用更少的资源却有更高的性能;
  • ECC更易扩展,随着RSA密钥更长只会让SSL/TLS面临更多的麻烦。
  • ECC并不太容易受到量子计算机的安全威胁,这是很重要的一点。

让我们对ECC的工作原理做一个粗略的解释,然后我们将讨论您在获得SSL/TLS证书时应该选择ECC而不是RSA所能获得的好处。

椭圆曲线加密101

很久以前,Vincent Lynch(现就职于DigiCert)写了一篇关于ECC的优秀总结,旨在五分钟内告诉你需要知道的一切。如果你能抽出时间,我强烈推荐它。以下是缩减版:

椭圆曲线密码学顾名思义,是一种利用椭圆曲线的数学原理进行加密的方式。感觉有点儿抽象,我之前提到过这一点,这也是我所指的部分。

我们从什么是x轴开始。你可能会笑出声,但这对理解ECC非常重要。椭圆曲线的每一点都通过x轴上映射——即图上的水平线——这就是椭圆曲线对称性的来源。

现在我们来讨论一下打点。画一条漂亮的椭圆曲线,通过在上面作图来解释我在说什么。在椭圆曲线上绘制A、B两个点,只有私钥的所有者知道。

连接A、B两点绘制一条直线,直线会与椭圆曲线在第三个位置相交,相交的点是我们所关心的。以x轴为对称轴会将此象限中的点(下图中第一象限的点)映射到第四象限。你可以看到,连接AB,与椭圆曲线在第三个位置相交,相交的点以X轴为对称轴进行对称得到点C。

现在重复一遍上面的操作,这次连接A、C两点绘制一条直线,在椭圆曲线上找到相交的点,以X轴为对称轴进行对称,绘制它的镜像点D。

以上称为打点。而交点的数量,或者说点的数量,只有私钥持有者知道,不具备相关知识的人是不可能解密它的。

显然,这是一个公钥密码系统,用于密钥对称交换,类似于RSA。但它通过椭圆曲线生成密钥,而非使用质因数分解。两者都完成相同的任务,但是ECC有一些明显的优势。

ECC密钥更短

RSA密钥很笨重。行业标准是2048位,而一些组织选择使用更长的密钥。还有一个主要的缺点:由于密钥的大小影响RSA加密所需的计算资源,密钥越大,所需资源越多,这可能导致您的网站性能滞后。当讨论RSA的扩展性问题时,我们会对此做更深入地讨论,但对RSA来说,更大的问题是密钥大小与它的安全性不相称。随着密钥长度的增长,安全性的强度不会以相同的程度提高。

相比RSA, ECC密钥不仅更短,而且很难破解。举例来说:根据通用安全(Universal Security)的一项研究,计算机破解一个228位RSA密钥所消耗的能量大约足以烧开一茶匙水。破解同样大小的228位ECC密钥所需的能量将超过煮沸地球上所有水所需的能量。

差距显而易见。

以下是一份ECC密钥大小的具体情况,以及与它们安全性对等的RSA密钥的大小:

ECC密钥大小 RSA密钥大小
160位 1024位
224位 2048位
256 位 3072位
384 位 7680 位
521 位 15360 位

需要关注的是,美国国家安全局(NSA)要求所有Top Secret文件和文档都必须使用384位ECC密钥加密。换作RSA,将是 7680位的RSA密钥,真的是相当笨重。

这很好地引出了我们下一论点。

ECC扩展性优于RSA

正如我们所提到的,从所需资源角度来说,RSA比ECC更昂贵。因式分解需要相当多的计算资源。现代加密技术面临的威胁越来越大,所需RSA密钥的长度也越来越大,它只会变得越来越昂贵。

这将最终导致RSA的消亡。

同时,还有一个更紧迫的问题。特别是对大型公司和企业来说。当规模足够大时, 所有这些SSL/TLS握手的费用和所有解密都可能成为您网络的最大负担。这就是为什么许多企业卸载SSL作为整个SSL/TLS部署的一部分。通过将这些流程卸载到专用设备上,可以释放应用服务器上的资源,从而提高网站的整体性能。

现在让我们应用我们所知道的ECC和RSA的差别:与ECC密钥相比RSA密钥扩展性更差。随着威胁的增长,密钥长度需要更大,这将给网络造成越来越大的压力。另一方面,ECC扩展性好,所需资源少。

对于规模较小的公司来说,这可能不是什么大问题,但随着规模的不断扩大,它终将成为你需要关心的问题。ECC会解决你的烦恼。

ECC更好的抵抗量子计算的安全威胁

在我们开始之前,为防评论区有人坚持认为:ECC在其最常见的迭代中并不具备抗量子性。它可以被Shor算法的修改版本破解。但是,有一种基于椭圆曲线的密码学展示出了前景:超奇异椭圆曲线同源密码术。

我们不打算讨论超奇异椭圆曲线和同源性图,因为量子计算目前还不可行,我也不是数学专业的学生。但SIDH,像其名称一样,相比竞争对手,它有两大优势:更短的密钥规模和完美的前向保密性。

简单介绍一下完美的前向保密性。很受隐私倡导者欢迎的一个属性,即使私钥被破解,它生成的会话密钥也不会受到损害。这在RSA中从技术上是可行的,但它需要寿命短的密钥,这就意味着需要定期的密钥旋转,如上所述,生成新的RSA密钥非常昂贵。而ECC密钥更短,容易旋转,很适合这种模型。

这是属于PFS的部分,我们将在今年春天晚些时候更深入地讨论它。

如何获得ECC SSL证书?

ECC SSL证书的获得与订购SSL证书一样简单。大多数SSL服务商和CA会在支持ECC的证书中提供一个ECC选项。虽然Sectigo和一些Symantec/DigiCert证书已经支持ECC,但并不是所有的都支持。

最重要的是:ECC的成本并不比RSA高。

无论从密钥大小,扩展性和长期有效性,它都是一个更好的密码系统。

您甚至不需要获取新的SSL证书来进行切换。大多数SSL服务商都免费提供重颁发SSL/TLS证书。您只需进入操作面板,选择证书,选择重颁发,使用ECC证书签名请求(CSR)来生成订单即可(前提是您的证书支持它)。

无论哪种方式,ECC证书都不难获得。为什么不用呢?

 

二月行业新闻回顾

本月大事件:

来自阿联酋的DarkMatter拥有一个证书颁发机构。

DarkMatter, 阿联酋一家颇具争议的公司,对证书颁发机构的可信度提出了一些问题。

据Reuters(路透社)报道,DarkMatter是“Project Raven” 的幕后黑手,在该项目中,NSA(美国国家安全局)的前雇员为UAE(阿联酋)实施了攻击性的黑客行动。包括监视人权活动家,据路透社报道,特别包括了针对被判10年监禁的Ahmed Mansoor的监视行动。

Claudio Guarnieri,Amnesty International的技术专家,他指出DarkMatter已经申请了Mozilla的证书根存储。不久之后,Electronic Frontier Foundation (EFF)要求Mozilla拒绝这个请求,并提到DarkMatter已经有了一个能够颁发浏览器信任的TLS证书的中间证书。

DarkMatter中间证书由QuoVadis签发,该证书颁发机构最近被DigiCert收购。

Mozilla的Wayne Thayer在Mozilla安全策略列表上发起了一场讨论,询问如何处理这个问题。“本讨论的目的是确定Mozilla是否应该通过将由QuoVadis签名的中间CA证书添加到OneCRL来不信任DarkMatter,并拒绝待处理的根包含请求。”Thayer写道。

本月短新闻:

文稿来源:Feisty Duck

Google Chrome 72 丢弃HPKP,不再支持TLS1.0和TLS1.1!

Mozilla发布Firefox 65 几个小时后,谷歌也发布了最新的Chrome 72,并为Windows、Mac、Linux和Android用户提供了更新的版本。

注:谷歌Chrome增加了下载驱动保护功能。

虽然在过去的3-4个版本中,谷歌在Chrome UI和UX(用户界面和用户交互)方面的变化已经给用户带来了很大的影响,但是如今的版本变化对浏览器的底层Web APIs和协议的影响更大。

在所有的变化中,Chrome 72有三个重要的更新是用户需要知道的。其中最重要的是完全删除对基于HTTP的公钥固定(HPKP)标准(RCF 7469)的支持。

谷歌早在2017年10月就宣布了关于HPKP的长期计划,并在2018年3月发布的Chrome 65中首次丢弃了HPKP。

由于已被丢弃,Chrome会在网站所有者的开发控制台上显示错误。现在它被弃用了,所以Chrome不再支持使用HPKP的网站,拒绝固定公钥。幸运的是,这不会影响到太多的网站,因为HPKP实现起来很麻烦,只有很少的网站曾经使用过它。

目前支持HPKP的网站所有者可能应该停止了,作为世界上最受欢迎的浏览器,Chrome将不再支持密钥固定。

Chrome 72版本的第二个主要变化是不会呈现任何通过FTP协议加载的资源。

Chrome将继续显示FTP目录列表,但当网站加载一个托管在FTP链接上的图像或JavaScript文件时,替代呈现图像或运行文件,Chrome会提示用户下载它。

Chrome 72的第三个主要变化是不再支持过时的TLS 1.0和TLS 1.1标准。这一举动只是Chrome 81采取的取消支持这两个标准的第一步。Chrome 81计划在2020年初发布。

谷歌曾在去年与Apple、Microsoft和Mozilla一起宣布过这些计划。Apple、Microsoft和Mozilla表示,他们将在各自的浏览器上执行这些计划。

Chrome 72不再支持TLS 1.0和TLS 1.1,这意味着当用户访问遗留有TLS 1.0或1.1证书的HTTPS站点时,Chrome会在开发人员控制台显示错误,但不会阻止用户访问站点。从Chrome 81开始,将会阻止用户访问。

Chrome现在的新版本号是72.0.3626.81。Windows、Mac、Linux和Android用户使用Chrome的内置更新器能够安装更新。完整的Chrome 71修改日志在此查看

在Chrome 72中,谷歌修复了58个安全漏洞,详情点击链接。来自 Chromium和 Google Developers 团队的两篇博文详细介绍了Chrome 72以开发人员为中心的特性。

文稿来源:ZDNet

新的TLS加密破坏攻击也会影响新的TLS 1.3协议

一个学术团队上周披露了一个新的加密攻击,它可以攻破加密的TLS流量,允许攻击者拦截并窃取以前认为安全可靠的数据。

这种新的降级攻击没有像大多数加密攻击那样具有花哨的名字,但是它甚至可以攻击TLS 1.3协议(2018年春天发布的TLS最新版本),其被公认为是安全的协议。

新的加密攻击本身并不新鲜,它是原始Bleichenbacher oracle攻击的新变种。

原始Bleichenbacher oracle攻击是以瑞士密码学家Daniel Bleichenbacher的名字命名的,他在1998年演示了第一次实际攻击,针对RSA使用PKCS#1 v1编码方式的加密系统。

多年来,密码学家已经找到了原始攻击的多种变种,例如

20032012201220142014201420152016(DROWN)2017(ROBOT), 和 2018

产生这些攻击变种的原因是:TLS加密协议的作者们仅仅以添加对策的方式使得猜测RSA解密密钥的尝试更加困难,而不是替换不安全的RSA算法。

这些对策已在TLS标准(RFC 5246)的第7.4.7.1节中定义,许多硬件和软件供应商多年来一直误解或未能遵循标准协议规定。

这些在实施恰当应对措施(指前文RFC文档描述的应对措施)方面的失败导致许多支持TLS的服务器,路由器,防火墙,VPNs和编码库仍然容易受到Bleichenbacher攻击变种的影响,这些攻击变种在不正确的应对措施中发现并利用了存在的问题。

2月6日发表的一篇技术论文中描述了最新的Bleichenbacher攻击变种,题为“ Bleichenbacher之猫的9条命:针对TLS协议实现的新缓存攻击 ”。

来自世界各地的七位研究人员再次发现另一种破解RSA PKCS#1 v1.5的方法,RSA PKCS#1 v1.5,目前用于加密TLS连接的最常见的RSA配置。除了TLS之外,这种新的Bleichenbacher攻击也会对谷歌新的QUIC加密协议有效。

研究人员表示,“为了攻破TLS的RSA密钥交换,攻击巧妙的利用了缓存访问时序的侧信道泄漏”。

即使是较新版本的TLS 1.3协议(其中RSA使用率保持在最低水平),在某些情况下也可以降级为TLS 1.2,新的Bleichenbacher变种攻击得以实施。

研究人员说“我们对九种不同的TLS实现进行了预防缓存攻击的测试,其中七个被发现是易受攻击的:OpenSSL, Amazon s2n, MbedTLS, Apple CoreTLS, Mozilla NSS, WolfSSL, 和 GnuTLS。”

2018年11月,当研究人员发表他们研究论文的初稿时,上述所有受影响的库同时发布了更新版本。

有关更多详细信息,请关注已经为这些新的Bleichenbacher攻击变种分配的安全漏洞CVE标识:CVE-2018-12404,CVE-2018-19608,CVE-2018-16868,CVE-2018-16869和CVE-2018- 16870。

两个不易受攻击的库分别是 BearSSL 和 谷歌的BoringSSL

文稿来源:ZDNet商业技术新闻网站

庆祝OpenSSL诞生20周年

在20年前,1998年12月23日,OpenSSL首个版本发布。OpenSSL并不是这个项目最初计划的名字(译注:原名OpenTLS),在官网上线前的几个小时,才被更改为了OpenSSL。来回顾一下OpenSSL早期的一些历史,其中的一些背景之前并没有文档记录。

早在20世纪90年代末,Eric Young和Tim Hudson就因为他们在开源SSLeay库上的工作成就而闻名。SSLeay被广泛用于Apache和(当时的)第三方SSL模块,用于构建开源、安全的Web服务器。在1998年,他们都为C2Net工作,改进SSLeay和使用它的产品。C2Net以其旗舰产品Stronghold Web Server而闻名。Stronghold Web Server是基于开源软件编译和构建的产品,并且提供支持服务。关键的一点,其能够在全球范围内提供和使用强加密技术。在现在看来这似乎微不足道,但在当时,从美国出口的加密产品,如Web服务器和浏览器,都只能使用有限的弱加密技术。(译注:Export of cryptography from the United States

Eric和Tim决定离开C2Net加入创造了商业SSL工具的RSA公司,因此SSLeay的未来并不明朗。1998年10月14日,在旧金山的第一次ApacheCon会议上,在我与Ralf Engelschall的一次讨论中诞生了OpenSSL项目,Ralf Engelschall是Apache核心开发人员。几个月后,我们继续了讨论,并于12月16日建立了一个邮件列表,邀请SSLeay专家Stephen Henson参与我们当时称为OpenTLS的项目。Apache核心开发者和Apache-SSL的作者Ben Laurie也在几天后独立宣布了启动SSLeay新版本的意图。

Ralf从公开的SSLeay 0.8.1和0.9.0b版本以及C2Net未发布的0.9.1b版本中获取源代码,将其导入OpenTLS CVS仓库。我们对这些文件做了一些清理工作,我们自己添加了一些补丁,也从社区中添加了一些知名的补丁,最终形成了0.9.1c版本。

就在公开发布之前的最后一刻,我们将项目名字从OpenTLS更改为OpenSSL:原因在于TLS协议RFC尚未发表,TLS作为缩略词在当时鲜为人知,而SSL缩略词已被广泛认可,因此在名称中使用SSL有助于用户理解SSLeay 到OpenSSL的过渡。幸运的是,我们同时保留了这两个域名。

1998年12月23日,我们开通了www.openssl.org网站,发布了OpenSSL-0.9.1 c版本和源代码库。

在这繁忙的一周中,我们一直在与Ben和Stephen沟通项目的对接和合并,圣诞节假期后不久,我们发布了完整的项目公告。所以最初的项目团队是由Ben Laurie, Paul Sutton, Ralf Engelschall, Stephen Henson,Mark Cox和我组成,除了Stephen Henson之外,所有人都是Apache HTTP Server的核心开发人员。

在最初的15年里,OpenSSL成员主要是由兼职的一小部分人组成,在那些年里,成员不断地发生波动和变化。大约5年前,我们扩大了这个小组,开始引入规范的政策。截至今天,我们已经形成一个体系,其中一组贡献者可以评审并对提交的代码作出变更,并且有管理委员会来监督这个项目。OpenSSL的资金主要来自赞助商的慷慨捐赠。我们还提供有偿合同支持服务,偶尔也会签订合同来开发某些新功能。我们使用这些资金主要是用来支付项目中全职研究员的工资。研究员们负责维护基础设施,修复bug和安全问题,审查补丁等更多的其他工作(您可以从发送到OpenSSL-project邮件列表的每月报告中看到他们在做什么)。许多公司还免费提供员工时间为OpenSSL项目工作。

第20年是激动人心的一年,对版本号方案进行了重大更改,许可协议切换到了Apache License 2.0,并且刚刚开始了一个针对初学者的新的FIPS验证项目。尽管SSL的所有版本现在都已被弃用(译注:SSL协议在SSLv3之后更名为TLS1.0协议)),但我们也不太可能很快将其重新命名为OpenTLS。

图为2018年11月OpenSSL管理委员会在爱丁堡城堡前举行的面对面会议。从左至右依次为: Paul Dale, Kurt Roeckx, Richard Levitte, Matt Caswell, Mark Cox, Tim Hudson。Viktor Dukhovni (图中未见)也是其中一员。

文稿来源:OpenSSL博客