关注网络安全
和行业未来

在喜达屋数据泄露中,5亿万豪宾客记录被盗

hansen阅读(174)评论(0)

全球最大的连锁酒店万豪国际集团今天披露,不知名的黑客入侵其子公司喜达屋酒店的客人预订数据库,并带走了大约5亿客人的个人信息。
喜达屋酒店及度假村集团于2016年被万豪国际以130亿美元收购。该品牌包括瑞吉酒店,喜来登酒店及度假村,W酒店,威斯汀酒店及度假村,雅乐轩酒店,Tribute Portfolio,Element Hotels,艾美酒店及度假村 ,豪华精选,福朋喜来登酒店及设计酒店。

该事件被认为是历史上最大的数据泄露事件之一,仅次于2016年雅虎黑客攻击,其中近30亿用户帐户被盗。
自2014年“未经授权的一方”设法未经授权访问喜达屋的客人预订数据库以及复制和加密信息后,自2014年以来,喜达屋物业遭到破坏。
万豪在收到内部安全工具发出的关于试图访问美国喜达屋客串预订数据库的警告后,于今年9月8日发现了该漏洞。
11月19日,对事件的调查显示,未经授权访问数据库,其中包含“2018年9月10日或之前有关喜达屋酒店预订的客人信息”。
被盗酒店数据库包含近3.27亿客人的敏感个人信息,包括姓名,邮寄地址,电话号码,电子邮件地址,护照号码,出生日期,性别,抵达和离开信息,预订日期和通信偏好。
什么令人更担忧?对于某些用户,被盗数据还包括支付卡号和支付卡到期日。

但据万豪称,“支付卡号码是使用高级加密标准加密(AES-128)加密的。”攻击者需要两个组件来解密支付卡号码,“此时,万豪还未能排除两者的可能性。”
该公司在一份声明中说:“该公司尚未完成在数据库中识别重复信息,但认为它包含了在喜达屋酒店预订的多达约5亿客人的信息。”万豪证实,对此事件的调查仅发现未经授权访问单独的喜达屋网络,而非万豪网络。它还开始向可能受影响的客户通报安全事件。
该酒店公司已经开始通知监管当局,并告知执法部门,并继续支持他们的调查。
由于数据泄露属于欧盟通用数据保护条例(GDPR)规定,如果发现违反这些规则的话,万豪可能会面临1700万英镑的最高罚款,即每年全球收入的4%。

赛门铁克发现朝鲜APT组织Lazarus攻击金融机构的关键性工具

hansen阅读(251)评论(0)

10月2日,美国国土安全部(DHS)下属的US-CERT发表了一则针对朝鲜APT组织Lazarus(Hidden Cobra)的技术性预警公告,公告指出,在DHS、DoT(财政部)和FBI的共同努力下,发现了Lazarus用于在全球实施ATM网络犯罪的恶意软件样本和多个威胁指标(IOCs),DHS把Lazarus组织的该系列恶意网络犯罪命名为“FASTCash”攻击。10月8日,安全公司赛门铁克(Symantc)发表报告声称,已经发现了Lazarus组织用于“FASTCash”攻击的关键性工具。

自2014年以来,Lazarus在全球多个国家实施了多起网络犯罪,入侵索尼公司、攻击韩国金融媒体机构、窃取孟加拉央行8100万美元、攻击美国国防承包商和比特币交易所、发起WannaCry勒索攻击。DHS透露,根据美国政府的可信合作伙伴评估,Lazarus仅针对金融机构的“FASTCash”攻击窃取金额就达数千万美元。

赛门铁克的发现

赛门铁克研究人员透露,Lazarus组织在开展FASTCash攻击时,首先会找点入侵目标银行的网络,接着渗透进入负责ATM交易的交换应用服务器,最终在这些服务器上部署一些此前我们从未识别的恶意软件 – (Trojan.Fastcash) 。之后,Lazarus攻击人员会发起欺诈性的现金提取请求,其部署的恶意软件则负责请求拦截监听,并会向负责ATM交易的交换应用服务器返回假冒的请求响应,以此实现对ATM系统的现金窃取。

根据US-CERT的预警公告反应,Lazarus于2017年发起了一起攻击事件,其分别从全球30多个不同国家的ATM机系统中同时提取转移了大量现金。同样的攻击也在2018年发生过,这一次,Lazarus从23个不同国家的ATM机系统中窃取了大量现金。

FASTCash Infographic.pngLazarus开展FASTCash攻击的具体流程

为了实现从ATM机系统中欺诈性的转移现金,Lazarus攻击者具体的做法是,在负责ATM交易的交换应用服务器中,向某个运行的合法进程注入一个高级交互执行程序(Advanced Interactive eXecutive, AIX),这个恶意的AIX程序包含了构造假冒ISO 8583消息报文的逻辑(ISO8583金融交易报文是银行业和金融服务业常用的数据消息格式,常用于终端交易设备中)。Lazarus这种假冒ISO 8583消息报文的技术此前未曾被发现过,通常的认为是Lazarus通过使用脚本来控制服务器实现转账交易欺骗。

ISO8583金融交易报文:是银行业和金融服务业常用的 ISO 标准,该标准指定了一个消息格式,设备和发卡行之间可以使用该消息格式来交换信用卡数据和借记卡数据,该标准通常为销售点设备和自动取款机所采用。消息本身通常包含有关交易金额、交易发起位置、卡的帐号以及银行分类代码的信息。接收数据的应用程序可以有多种用途,例如在多个银行帐户之间转移资金、支付账单或手机充值。

赛门铁克及时发现了这种注入到ATM交易应用服务器中的恶意软件,并把它命名为 Trojan.Fastcash,实质上它属于木马类恶意程序,且包含了两个主要功能:

1、监视传入服务器的消息,并在请求到达交易服务器之前,拦截攻击者生成的欺诈性交易请求

2、为了形成欺诈性交易请求,其中包含了生成一个假冒响应的程序逻辑

赛门铁克对FASTCash攻击的发现样本

一旦Trojan.Fastcash被成功部署在负责ATM交易的应用服务器中,其将会读取所有传入服务器的网络流量,并扫描流量中包含的 ISO 8583报文请求,而且它还会探测流量消息中,攻击者用来执行交易的银行主账户号(Primary Account Number,PAN),如果有银行主账户号出现,Trojan.Fastcash就会尝试修改涉及该账户号的消息。

Lazarus会根据不同的金融机构目标,实行不同的账户号消息修改方法,如果消息修改成功,Trojan.Fastcash会针对向ATM应用服务器发起的欺诈请求,返回一条假冒的现金转账批准响应,最终,Lazarus的转账申请就会被ATM应用服务器放行,从而成功实施了现金转账。

经分析,以下是Trojan.Fastcash用来生成假冒批准响应的一个程序逻辑。这个特殊样本会根据攻击者传入的欺诈请求,构造以下不同三个假冒响应之一。

当ISO8583报文消息的类型标识 == 200,也就是ATM发生交易行为,和POS机型磁条卡的服务点输入方式码从90开始时,Trojan.Fastcash有以下程序逻辑:

If Processing Code starts with 3 (Balance Inquiry):

Response Code = 00 (Approved)

Otherwise, if the Primary Account Number is Blacklisted by Attackers(否则,如果攻击者将主帐号列入黑名单):

Response Code = 55  (Invalid PIN)

All other Processing Codes (with non-blacklisted PANs):

Response Code = 00 (Approved)

在这种情况下,攻击者似乎内置了根据他们自己设置的黑名单账户号有选择性地进行转账交易,但是,该功能在这样本中并没有成功实现,其黑名单检查机制总是返回“False”。

赛门铁克发现了和Trojan.Fastcash相关的几种不同特洛伊木马变种,且每种都使用了不同的响应逻辑,赛门铁克认为这些变种都是针对不同金融机构的特定交易处理网络而定制的,因此其具备的响应逻辑有所不同。

另外,被Lazarus组织用于FASTCash攻击的银行主账户号(PAN)都是真实存在的,根据US-CERT的预警公告,这些被攻击者用来发起交易的账户号不太活跃或是零余额状态,而攻击者控制这些账户号的方法也暂不清楚,可能是攻击者的自行开卡,也可能是其它攻击活动中窃取的账户。

截至目前,在所有对FASTCash攻击的报告中,都提到了由于银行应用服务器的AIX操作系统更新不及时,存在漏洞,导致被攻击者入侵的说法。

Lazarus对金融机构的持续威胁

最近的FASTCash攻击表明,对金融机构的攻击不是Lazarus的一时兴起,很有可能是其长期的主要活动。如同2016年的对孟加拉国央行的现金转移案一样,FASTCash攻击反映了Lazarus对银行系统和交易处理协议有着深入的研究理解,并且能发现存在漏洞的银行网络,并成功从中窃取转移现金,作案手法相当专业。

总之,Lazarus会持续对金融部门造成严重威胁,相关单位和部门应采取必要措施,确保其支付系统及时更新并处于安全状态。

防护建议

1、及时更新操作系统和相关应用软件;

2、关注并更新近期容易被攻击者利用的应用软件漏洞;

3、及时更新应用服务中涉及的AIX操作系统。

IoC

D465637518024262C063F4A82D799A4E40FF3381014972F24EA18BC23C3B27EE (Trojan.Fastcash Injector)

CA9AB48D293CC84092E8DB8F0CA99CB155B30C61D32A1DA7CD3687DE454FE86C (Trojan.Fastcash DLL)

10AC312C8DD02E417DD24D53C99525C29D74DCBC84730351AD7A4E0A4B1A0EBA (Trojan.Fastcash DLL)

3A5BA44F140821849DE2D82D5A137C3BB5A736130DDDB86B296D94E6B421594C (Trojan.Fastcash DLL)

*来源:symantec

新的Android API可以让开发人员在他们的应用程序中推送更新

hansen阅读(182)评论(0)

您可能已经在网上阅读过,谷歌正在授予Android应用开发者强制安装应用更新的权力......但事实并非如此。
相反,这家科技巨头正在提供一项新功能,可以帮助用户随时拥有最新的Android应用程序,是的,它是可选的。
随着在2018年Android Dev Summit上推出一系列新工具和功能,Google还推出了一款名为“应用内更新”的新API,旨在帮助开发人员确保用户运行最新,最好的 他们的应用程序版本。

Android的新应用内更新API如何运作?
需要注意的是,Android的新应用内更新API如果用户选择不更新,则不会强制或锁定用户。
相反,该API旨在积极地向用户通知最新的可用更新,并在不关闭应用或打开Google Play商店的情况下为他们提供流畅的应用内安装体验。

正如谷歌工程总监Aurash Mahbod所解释的那样,应用内更新API为Android开发人员提供了两种方式来向用户推送新的更新,如下所述:
1)即时应用内更新(针对关键补丁) - 应用开发者可以向用户显示全屏消息,通知他们新的更新,用户可以选择下载(如果需要)并立即安装 在他们可以使用该应用程序之前,在应用程序本身。
出于显而易见或其他原因,用户可以拒绝立即更新并继续使用该应用程序,以防它们未连接到Wi-Fi或电池电量不足。
2)灵活的应用程序内更新(定期更新) - 使用此选项,Android应用程序开发人员可以向用户显示一个小的“可用更新”通知,让他们可以选择接受它,然后在新版本应用程序中继续使用该应用程序 在后台下载。

下载应用程序后,将在用户下次重新打开应用程序时安装该应用程序。
灵活更新还为用户提供“不立即”选项,用户可以选择该选项以防他们不想安装更新。
这个概念很好,绝对不是新的,因为许多应用程序已经有自定义机制来确定用户是否运行过时版本,然后提示他们从Play商店安装最新版本。 但是,新的API使整个过程变得标准,流畅和简单,为用户提供了全新的体验。

Android In-app Updates API

Aurash还表示,该公司目前正在测试Google Chrome for Android中的In-App Updates API,并且正在为早期访问合作伙伴的开发人员提供新API。 它很快就会面向所有开发人员。
谷歌还表示,Android开发人员将能够完全自定义更新流程,使其成为您应用的一部分,这表明所有应用都不具备相同的应用内更新体验

后量子密码学指南

hansen阅读(227)评论(0)

对于如TLS流量、医疗数据库、区块链等等许多需要高度保障安全的应用方向,前向保密绝对必不可少,但仅仅防止黑客快速解密敏感信息是远远不够的,威胁模型还应该考虑攻击者在收集密文多年之后解开密文的情况。

可能打破的前方保密的潜在方式是:增加的计算能力和数量基础理论的突破,这会使攻击密码变的很简单。

但是,除非有人找到了用于分解大整数的多项式时间算法,否则这种风险对于当前的密码算法来说可能性很小,我们应该更关注量子计算机的成功开发。

量子计算入门

量子计算机不仅仅是大规模并行的经典计算机。人们常常认为,由于量子比特可以同时占据0和1,因此n比特量子计算机可以同时处于2 n个状态,因此可以非常快速地计算NP。

其实情况并非如此,因为测量量子态会破坏大部分原始信息。例如,量子系统完全了解物体的动量和位置,但任何动量测量都会破坏有关位置的信息,反之亦然。这被称为海森堡不确定性原理。

因此,成功的量子算法由量子比特的一系列变换组成,使得在计算结束时,测量系统的状态不会破坏所需的信息。事实上,已经证明,不存在量子算法同时尝试解决某些NP完全问题并输出正确的量子算法。换句话说,任何用于解决硬经典问题的量子算法都必须利用具体结构。

今天,有两种这样的算法可用于密码分析。

快速计算大数的能力将破坏RSA和离散的基于日志的加密。整数分解的最快算法是一般数字域筛,它在亚指数时间内运行。

在1994年,Peter Shor开发了一种用于整数分解的量子算法(Shor算法),该算法在多项式时间内运行,因此能够破坏任何RSA或离散的基于对象的密码系统(包括那些使用椭圆曲线的密码系统)。这意味着如果有人要构建量子计算机,那么所有广泛使用的公钥密码都是不安全的。

第二个是Grover的算法,它能够在O(√n)时间内反转函数。该算法会通过根因子降低对称密钥加密的安全性,因此AES-256只能提供128位的安全性。类似地,找到256位散列函数的前映像只需要2 128次。由于将哈希函数或AES的安全性提高两倍并不是非常繁琐,因此Grover的算法不会对对称加密造成严重威胁。此外,建议用于加密使用的伪随机数发生器都不会受到量子计算机发明的影响,除非Grover算法引起的O(√n)因子。

后量子算法的类型

后量子密码学是对密码系统的研究,它可以在经典计算机上运行,​​即使对手拥有量子计算机也是绝对安全的。

最近,NIST启动了标准化后量子加密的过程,目前正在审查第一轮提交。这些提交中最有希望的包括基于格,同源,Hash函数和编码的密码系统。

在深入研究每类提交之前,我们简要总结一下每种类型的密码系统固有的权衡,并与当前(非后量子)椭圆曲线密码学进行比较。请注意,代码和同基因能够生成数字签名,但没有向NIST提交此类方案。

image.png

在安全性证明方面,上述密码系统都没有减少到NP-Hard(或NP完全)问题。在格和编码的情况下,这些密码系统基于NP难问题的轻微修改。基于散列的构造依赖于良好散列函数的存在,并且不进行其他加密假设。

最后,基于同基因的密码学基于一个被推测为难的问题,但与NP-Hard问题或先前的加密假设不相似。然而,值得一提的是,正如我们无法证明任何经典算法在多项式时间内都不易破碎(因为P可能等于NP),可能是量子计算机认为难以解决的问题。此外,一个不会减少到一些NP难或完整问题的密码系统本身不应该是一个标记。

在后量子加密的所有方法中,对格子的研究是最活跃和最灵活的。它们具有很强的安全性,可以进行密钥交换,数字签名以及完全同态加密等更复杂的构造。尽管格子密码系统的优化和安全性证明都需要极其复杂的数学,但基本思想只需要基本的线性代数。假设您有一个形式的线性方程组,比如说:

求解x是一个经典的线性代数问题,可以使用高斯消元法快速求解。

另一种思考方式是我们有一个神秘的功能:

image.png

给定一个向量的地方a,我们看到了结果ax,而不知道x。在查询此函数足够多次后,我们可以在很短的时间内得到f(通过求解上面的方程组)。这样我们就可以将线性代数问题重新定义为机器学习问题。

现在,假设我们引入少量噪声到我们的功能,使相乘后x和a,我们增加一个误差项e,降低了整个事情的一个模(中型)q

image.png

学习这种带噪的神秘函数已经在数学上被证明是非常困难的。直觉是在我们在非噪声情况下使用的高斯消除过程的每一步中,误差项变得越来越大,直到它超越了关于函数的所有有用信息。在密码学文献中,这被称为带有错误学习问题(LWE)。

基于LWE的密码学被称为基于格的密码学的原因,已知NP-Hard,LWE难以证明依赖于在称为格子的东西中找到最短向量。我们不会在这里深入研究格子的数学,但可以认为格子是n维空间的平铺:

image.png

格子由坐标向量表示。在上面的例子中,晶格的任何点可通过将达到(经由正常矢量相加)。最短向量问题(SVP)说:给定一个点阵,找到长度为向量的元素最短。很难的直观原因是并非所有给定晶格的坐标系都同样易于使用。在上面的例子中,我们可以用三个非常长且靠近的坐标向量来表示晶格,这使得寻找靠近原点的向量更加困难。事实上,有一种规范的方法可以找到格子的“最坏可能”表示。当使用这样的表示时,已知最短向量问题是NP-hard。

在研究如何使用LWE进行抗量子密码学之前,我们应该指出LWE本身不是NP-Hard。它不是直接降低到SVP,而是降到SVP的近似值,推测它是不是NP-Hard。尽管如此,目前还没有用于求解LWE的多项式(或次指数)算法。

现在让我们使用LWE问题来创建一个实际的密码系统。最简单的方案是由Oded Regev在他的原始论文中创建的,证明了LWE问题的硬度。这里,秘密密钥是具有整数条目mod的n维向量q,即上面提到的LWE秘密。公钥是A前面讨论的矩阵,以及LWE函数的输出向量:

image.png

这个公钥的一个重要特性是,当它乘以向量时,我们得到了大致的误差项:(-sk,1)0。

为了加密一些信息m,我们取结果的最后一个坐标中的随机列A和编码的总和,m加上0,如果m是0,q/2如果m是1。换句话说,我们选择x0或1 的随机向量,并进行计算:

image.png

直觉上,我们刚刚评估了LWE函数(我们知道它很难破解)并在此函数的输出中编码了我们的位。

解密是有效的,因为知道LWE秘密将允许收件人收回消息,加上一个小错误术语:

image.png

正确选择错误分布后,它永远不会使消息失真超过q/4。接收方可以测试输出是否更接近0或相应地q/2 mod q解码该位。

该系统的一个主要问题是它具有非常大的密钥。要加密一位信息,需要安全参数中大小为n 2的公钥。然而,格子密码系统的一个吸引人的方面是它们非常快。

自Regev的原始论文以来,围绕基于格的密码系统进行了大量工作。改进其实用性的关键突破是Ring-LWE的开发,这是LWE问题的变体,其中键由某些多项式表示。这导致密钥大小的二次减少,加速加密和解密,仅使用n*log(n)操作(使用快速傅立叶技术)。

在考虑用于NIST PQC标准的许多基于晶格的密码系统中,特别值得一提的两个是晶体结构,Kyber和Dilithium。

Kyber是一种密钥封装机制(KEM),它遵循与上述系统类似的结构,但使用一些花哨的代数数论来获得比Ring-LWE更好的性能。对于合理的安全参数,密钥大小约为1kb(仍然很大!)但加密和解密时间大约为0.075毫秒。考虑到这种速度是通过软件实现的,Kyber KEM似乎很有希望进行后量子密钥交换。

Dilithium是一种基于类似Kyber技术的数字签名方案。它的详细信息超出了本博文的范围,但值得一提的是它也实现了相当不错的性能。公钥大小约为1kb,签名为2kb。它也非常高效。在Skylake处理器上,计算签名所需的平均周期数约为200万。验证平均需要390,000个周期。

编码

纠错码的研究在计算机科学文献中有着悠久的历史,可以追溯到Richard Hamming和Claude Shannon的突破性工作。我们无法在一篇简短的博文中开始研究这个深层领域的表面,但我们会给出一个快速概述。

在传递二进制消息时,错误可能以位翻转的形式发生。纠错码提供了以消息紧凑性为代价承受一定数量的位翻转的能力。例如,我们可以通过将0编码为000而将1编码为111来防止单比特翻转。这样,接收器可以通过对三个比特进行多数表决来确定101实际上是111,或者001是0。但是,这个编码无法纠正两个位被翻转的错误,因为转换为001的111将被解码为0。

最突出的纠错码类型称为线性码,可以用k x n矩阵表示,其中k是原始消息n的长度,是编码消息的长度。通常,在不知道底层线性编码的情况下解码消息在计算上是困难的。这种硬度巩固了McEliece公钥密码系统的安全性。

在高级别,McEliece系统中的秘密密钥是G来自称为Goppa码的一类代码的随机码(表示为矩阵)。公钥是矩阵SGP,其中S是具有二进制条目的可逆矩阵并且P是置换。为了加密消息m,发送方计算c = m(SGP) + e,其中e是随机错误向量,其中包含编码能够纠正的错误数量。为了解密,我们进行计算,这样就可以纠正添加的错误术语。通过计算可以轻松恢复该消息:cP-1 = mSG + eP-1mSGemSS-1。

与格子一样,基于代码的密码术也存在密钥是大矩阵的事实。使用推荐的安全参数,McEliece公钥大约为1 MB,私钥为11 kb。目前正在尝试使用称为准循环中等密度奇偶校验码的特殊类代码,这些代码可以比Goppa代码更简洁地表示,但是这些便阿门的安全性比Goppa码的研究更少。

同源

椭圆曲线密码学领域因使用相当多的奥术数学而臭名昭着。同基因将这一点提升到一个全新的水平。在椭圆曲线加密中,我们使用Diffie-Hellman类型协议来获取共享秘密,但是我们不是将组元素提升到某个幂,而是遍历椭圆曲线上的点。在基于同源的密码学中,我们再次使用Diffie-Hellman类型协议,但我们不是通过椭圆曲线上的点遍历,而是通过一系列椭圆曲线本身。

image.png

同种映射变换,使得上述第一曲线的组结构被反映在第二椭圆曲线到另一个的功能。对于那些熟悉群论的人来说,它是一个群同态,有一些附加的结构来处理每条曲线的几何。当我们将注意力限制在超奇异椭圆曲线(我们在此不会定义)时,每条曲线都保证从其到其他超奇异曲线具有固定数量的同胚。

现在,考虑通过从我们的起始曲线检查该形式的所有同基因,然后从这些曲线中检查所有同基因来创建的图,依此类推。这个图表在高度结构化的意义上说,如果我们从第一条曲线开始随机游走,击中特定其他曲线的概率可以忽略不计(除非我们采取指数级的步骤)。在数学术语中,我们说通过检查所有这些同源生成的图是一个扩展图(以及Ramanujan)。这种扩展特性正是使基于同源的密码学安全的原因。

对于超奇异同源 Diffie-Hellman(SIDH)方案,密钥是同源链,公钥是曲线。当Alice和Bob组合这些信息时,他们会获得不同的曲线,但具有相同的不变量。对于加密的目的而言,j-invariant不是那么重要,而是它是Alice和Bob完成密钥交换后可以很容易地计算的数字。

与其他后量子方案相比,基于同源的密码学具有极小的密钥大小,仅使用330个字节用于公钥。不幸的是,在这篇文章中讨论的所有技术中,它们是最慢的,对于密钥生成和共享秘密计算都需要11-13毫秒。然而,他们确实支持完美的前向保密,这不是其他后量子密码系统所拥有的。

基于Hash的签名

已经有许多基于哈希的签名的友好介绍,所以我们对它们的讨论相当高级。简而言之,哈希签名使用哈希函数的输入作为密钥并输出作为公钥。这些密钥仅适用于一个签名,因为签名本身会显示密钥的一部分。基于散列的签名的极端低效导致区块链使用Merkle树来减少空间消耗(是的,比特币中使用的相同Merkle树)。

不幸的是,用哈希构造KEM或公钥加密方案是不可能的。因此,基于散列的签名不是完整的后量子密码学的解决方案。而且,它们不是空间有效的; 一种更有前途的签名方案SPHINCS产生41kb的签名和1kb的公钥/私钥。另一方面,基于散列的方案非常快,因为它们只需要计算散列函数。它们还具有极强的安全性证据,完全基于存在具有抗冲突和抗图像抗性的散列函数的假设。由于没有任何迹象表明当前广泛使用的哈希函数(如SHA3或BLAKE2)容易受到这些攻击,因此基于哈希的签名是安全的。

小贴士

后量子密码学是一个令人难以置信又令人兴奋的研究领域,在过去十年中已经取得了巨大的增长。虽然这篇文章中描述的四种类型的密码系统已经得到了很多学术上的关注,但是没有一种被NIST批准,因此不推荐用于一般用途。许多方案的原始形式不具备性能,并且受到各种优化的影响,这些优化可能会或可能不会影响安全性。实际上,已经证明多次尝试为McEliece系统使用更节省空间的代码是不安全的。就目前而言,从后量子密码系统中获得最佳安全性需要牺牲一些空间或时间。基于环形点阵的密码学是灵活性方面最有前途的工作途径(签名和KEM,也是完全同态加密),但它所基于的假设仅在几年内得到了强烈的研究。现在,最安全的赌注是使用McEliece和Goppa代码,因为它已经经受了数十年的密码分析。

来自FreeBuf.COM

ct-exposer:通过搜索CT日志发现子域

hansen阅读(276)评论(0)

什么是证书透明度(简称CT)?

证书透明度,(Certificate Transparency)是谷歌力推的一项拟在确保证书系统安全的透明审查技术。其目标是提供一个开放的审计和监控系统,可以让任何域名的所有者,确定CA证书是否被错误签发或恶意使用。TLS的缺点是你的浏览器隐性包含了一个大型受信任CA列表。如果任何这些CA恶意为域创建新证书,则你的浏览器都会信任它。CT为TLS证书信任提供了额外的安全保障:即公司可以监控谁为他们拥有的域创建了证书。此外,它还允许浏览器验证给定域的证书是否在公共日志记录中。

而这些日志对于渗透测试人员或红队而言,无疑是座信息的宝库。

ct-exposer能为我们做什么?

ct-exposer将查询给定域的CT日志,然后尝试对域进行DNS查找以获取DNS中存在的域。根据经验,到目前为止ct-exposer为我查找到了许多使用“site:domain.com”谷歌搜索找不到的子域。请记住,无法解析的域可以是旧域或仅是内部域(例如:你需要访问内部DNS服务器才能解析它们)。

安装依赖

Python3,gevent,requests 和 urllib3,pip3 install -r requirements.txt

使用

来自FreeBuf.COM

Chrome 70正式向所有HTTP网站发出红色“不安全”警告!

hansen阅读(433)评论(0)

10月17日,坐拥10亿用户的Chrome浏览器正式上线70版本。作为第一个采用TLS1.3正式版的Chrome版本,在安全新功能方面,Chrome 70进一步升级了HTTP页面“不安全”显示标识,即当用户输入数据时,HTTP 站点将显示一个红色的“Not Secure”(不安全)警告。此次更新是谷歌“HTTPS 100%”计划的一部分,其目标是所有网站都通过HTTPS加载到Chrome上,从而强调HTTP网站不应被信任。

Chrome 70 针对含用户输入的HTTP 网页的处理

红色不安全警告示意图

(测试时间:10月18日13:45分)

谷歌重推HTTPS加密,取得惊人进展

谷歌多年来一直致力于推进 HTTPS 的加密普及,为了营造安全的上网环境,通过改变 Chrome 用户界面显示取得显著成效。数据显示,安卓上的Chrome加密流量从42%增长到76%;Chrome OS上Chrome加密流量从67%增长到85%;Top 100的网站中默认使用HTTPS的站点从37个增长到83个。

Google 对于网站应为HTTPS 一直以来不断推广,相关的执行时程表及政策如下:

经过十年的发展,Chrome已经是市场份额最高的桌面和移动浏览器了,主导地位不可撼动。在Chrome浏览器的引领下,其他浏览器也在逐步实施弃用HTTP的计划,Firefox宣布将所有HTTP页面标记“不安全”,Safari也对HTTP页面添加“不安全”警告,HTTP页面被警告的范围将越来越大。根据NetMarketShare 公布的2018年5月最新浏览器数据,Chrome、Firefox及Safari等宣布将HTTP页面标记“不安全”的浏览器,几乎占了整体市场份额的80%,移动端方面甚至超过90%

为什么主流浏览器纷纷抛弃HTTP协议?

1、随着大数据的崛起,用户隐私数据价值炙手可热。

2、用户安全意识逐渐提高,95%的用户会因为[不安全]提示而放弃访问,从而造成用户流失。

3、隐私数据泄露问题日益突出。

4、HTTPS为信息安全必选。

网站采用HTTPS协议已是大势所趋。既然主流浏览器都在建议HTTP协议网站安装SSL证书,为避免您的网站被贴上红色“不安全”的警告标签,造成用户流失对网站失去信任,那些还在采用HTTP协议的网站站长们需要做好应对准备了!

OpenSSL 1.1.1发布 正式支持TLS1.3

Jesdoit阅读(812)评论(0)

在经历两年的修补改进后,OpenSSL于近日发布了1.1.1版本并承诺至少投入5年的时间支持该版本。

OpenSSL的Matt Caswell在博文中感谢了对OpenSSL近5000次的优化的两百多名志愿者,以及所有下载测试版本并提供反馈的各种用户。

OpenSSL1.1.1的一大亮点无疑是TLS1.3。这个在一个月前由IETF发布为RFC8446的最新协议改写了以往的旧标准,其包含全新的特性备受瞩目并在OpenSSL的1.1.1版本中展现。

更重要的是,OpenSSL 1.1.1是个API,且ABI兼容OpenSSL 1.1.0。所以大多数使用1.1.0的应用程序只需通过新的OpenSSL版本就可以获得TLSv1.3的许多好处。尽管如此,由于TLSv1.3与TLSv1.2的工作方式非常不同,少数应用程序可能会遭遇警告。 有关更多详细信息,请参阅OpenSSL wiki上的TLSv1.3页面

文章还指出了OpenSSL 1.1.1中具体包含的新特性:

  • 由于减少了客户端和服务器之间所需的往返次数,缩短了连接时间
  • 在某些情况下,客户端能够立即开始将加密数据发送到服务器而无需与服务器进行任何往返(称为0-RTT或“早期数据”)。
  • 由于删除了各种过时和不安全的加密算法以及更多连接握手的加密,提高了安全性

以及OpenSSL 1.1.1新增的:

  • 完全重写OpenSSL随机数生成器以引入以下功能
    • 默认的RAND方法现在使用符合NIST标准SP 800-90Ar1的AES-CTR DRBG。
    • 通过种子链支持多个DRBG实例。
    • 有一个公共和私有DRBG实例。
    • DRBG实例是分叉安全的。
    • 可启用将所有全局DRBG实例保留在安全堆上。
    • 公共和私有DRBG实例每线程锁定自由操作
  • 支持各种新的加密算法,包括:
    • SHA3
    • SHA512 / 224和SHA512 / 256
    • EdDSA(包括Ed25519和Ed448)
    • X448(添加到1.1.0中的现有X25519支持)
    • 多素数RSA
    • SM2
    • SM3
    • SM4
    • SipHash
    • ARIA(包括TLS支持)
  • 显著的侧通道攻击安全性改进
  • 最大片段长度TLS扩展支持
  • 一个新的STORE模块,它实现了一个基于统一和URI的存储读取器,可以包含密钥,证书,CRL和许多其他对象。

此外,由于OpenSSL 1.1.0不是LTS版本,因此根据OpenSSL之前的公告和此次发布的策略,它将立即开始接收安全修复程序,并且将在一年内停止获得所有支持(不再维护)。

之前的LTS版本(OpenSSL 1.0.2)将继续获得全面支持,直到今年年底。 之后它只会收到安全修复程序。 它将在2019年底停止接收所有支持。笔者强烈建议该版本的用户升级到OpenSSL 1.1.1。

Matt Caswell还透露,下一个OpenSSL的重要功能将是新的FIPS模块。

离不开OpenSSL的你,是否已经跃跃欲试了呢?

 

稿源:OpenSSL blog

八月行业新闻回顾

Jesdoit阅读(559)评论(0)

本月大事件:TLS 1.3 正式发布

盼望着,盼望着,TLS协议1.3版本(RFC 8446)终于在本月发布啦!

我们在之前的新闻简报中多次讨论过TLS 1.3的发展。新的协议版本弃用了许多有问题和不安全的做法,包括没有前向保密的静态RSA密码,带有MAC-then-Encrypt的CBC模式,不安全的哈希以及许多其他旧算法。新功能包括了删除一次往返的来回握手,可选且有争议的零往返模式,加密证书,AEAD模式的更安全的随机数构造以及RSA-PSS签名。

TLS 1.3的开发花费的时间比预期的要长,因为许多部署的设备没有正确实现TLS握手,或者在看到尚未知的TLS版本时以其他方式破解。

TLS 1.3的部署在最终确定之前已经开始;各种浏览器和服务器已支持草稿版本。预计他们很快就会进入最终版本。

IETF发布了一篇介绍新TLS版本的博客文章,Cloudflare的Nick Sullivan撰写了非常详细的描述

短新闻

  • 8月1日起,证书颁发机构不再允许使用两种有问题的验证方法。这些方法允许在没有任何技术验证的情况下检查域的所有权。 Digicert解释了细节
  • Mega.nz同步客户端包含一个带有用于localhost连接的私钥的证书
  • 许多人在TLS研究中使用Alexa Top 1 Million列表,因此了解它的可靠性非常重要。几家机构的研究人员查看了这份名单,发现了几个值得注意的特性;比方说,每天都有大变化。
  • 8月1日起,苹果公司停止信任部分赛门铁克证书,并发布了一项计划,表明它将在2018年晚些时候停止相信其余的证书。
  • Facebook发布了Fizz,一个支持TLS 1.3的开源库。
  • 微软接受了Let's Encrpyt的根证书。这意味着所有主流浏览器现在都直接接受Let's Encrpyt的根。由于使用了由IdenTrust证书颁发机构签名的交叉签名中间件,Let's Encrypt早已被大部分浏览器接纳。
  • RFC 8410为X.509证书中的Ed25519指定了现代椭圆曲线加密算法的标识符。
  • RFC 8422定义了TLS 1.2及更早版本的现代椭圆曲线(曲线25519,曲线448)。
  • OpenSSL发布了1.1.0i和1.0.2p版本,修复了之前公开的两个不太严重的安全问题。
  • 谷歌发布了一份关于HTTPS安全团队的Emily Schechter的采访
  • MesaLink是一个用Rust编写的TLS库,旨在与OpenSSL兼容。
  • Trail of Bits探索使用Rowhammer式攻击来注入错误并导致RSA-CRT错误。 RSA-CRT算法的属性意味着签名中的错误计算允许攻击者正常地计算私钥。
  • 一篇研究论文研究了加密库中素性测试的稳健性,并发现了几个问题。
  • 研究人员在TLS中发布了针对CBC模式的Lucky Thirteen攻击的新变种,影响了亚马逊的s2n,GnuTLS,mbed TLS和wolfSSL。
  • Thyla van der Merwe发表了她的博士论文,该论文分析了TLS 1.3。
  • 谷歌最近宣布,它打算取消对Chrome中令牌绑定的支持,默认情况下从未启用。 另一方面,微软宣布它计划在未来如何使用令牌绑定。 令牌绑定可以将应用程序级令牌(如cookie)直接绑定到TLS连接,但这是否具有实际用途仍然存在争议。
  • 汉堡大学的研究人员研究了如何将TLS会话恢复用作跟踪机制
  • Ian Foster和Dylan Ayrey发布了有关改变所有权的域名证书的研究。这项工作也在DEFCON上发表。这会导致两个有问题的情况:首先,旧的域所有者可能仍然拥有允许对证书进行中间人攻击的私钥。其次,对于许多域共享单个证书的云提供商,这可能允许域所有者撤销该证书,从而导致拒绝服务。
  • 黑帽会议上的一次演讲着眼于TLS 1.3和0-RTT的重播攻击
  • 今年的Pwnie最佳加密攻击奖授予了ROBOT攻击。
  • 普林斯顿大学的研究人员研究了证书发布过程中的BGP攻击,并在USENIX会议上发表了他们的研究成果
  • Brigham Young大学的一个研究小组提出了一个支持直接TLS的套接字API。它发布在USENIX会议上,并在Facebook的互联网防御奖中获得第二名。

稿源: Feisty Duck

Cloutflare:TLS 1.3解读 你想了解的都在这儿

Jesdoit阅读(881)评论(0)

在过去的五年中,互联网工程任务组(IETF),即定义互联网协议的标准机构,一直致力于标准化其最重要的安全协议之一的最新版本:传输层安全性(TLS)。 TLS用于保护Web(以及更多!),提供加密并确保每个HTTPS网站和API的真实性。 最新版本的TLS,TLS 1.3(RFC 8446)于本月10日发布。 这是该协议的第一次重大改革,带来了重大的安全性和性能改进。 本文转载自Cloudflare博客,深入探讨了TLS 1.3中引入的变化及其对互联网安全未来的影响。

一场变革

Cloudflare提供安全性的一个主要方式是支持网站和API等Web服务的HTTPS。使用HTTPS(“S”代表安全),浏览器和服务器之间的通信通过加密和经过身份验证的通道传输。通过HTTPS而不是HTTP提供内容可以让访问者确信他们看到的内容是由合法内容所有者呈现的,并且通信是安全的,不会被窃听。在这个世界里,在线隐私比以往任何时候都更加重要,这是一个大问题。

使HTTPS安全的引擎下的机制是一种称为TLS的协议。它源于九十年代中期在Netscape开发的称为安全套接字层(SSL)的协议。到20世纪90年代末,Netscape将SSL交给IETF,IETF将其重命名为TLS,并从此成为该协议的管理者。许多人仍将Web加密称为SSL,即使绝大多数服务已切换到仅支持TLS。 SSL这个术语继续受到人们的欢迎,而Cloudflare通过无钥匙SSL和通用SSL等产品名称使这个术语保持活力。

在IETF中,协议称为RFC。 TLS 1.0是RFC 2246,TLS 1.1是RFC 4346,TLS 1.2是RFC 5246.今天,TLS 1.3发布为RFC 8446. RFC通常按顺序发布,保留46作为RFC编号的一部分是一个很好的延续。

在过去几年中,TLS已经被发现诸多的问题。 首先,实现TLS的代码存在问题,包括Heartbleed,BERserk,goto fail;等等。 这些问题不是协议的基础,而且主要是由于缺乏测试。 像TLS Attacker和Project Wycheproof这样的工具有助于提高TLS实施的稳健性,但TLS面临的更具挑战性的问题与协议本身有关。

TLS由工程师使用数学家的工具设计。 SSL时代的许多早期设计决策都是使用启发式方法和对如何设计健壮的安全协议的不完全理解。 也就是说,这不是协议设计者(Paul Kocher,Phil Karlton,Alan Freier,Tim Dierks,Christopher Allen等人)的错,因为整个行业仍在学习如何正确地做到这一点。 在设计TLS时,关于安全认证协议设计的正式论文,如Hugo Krawczyk的标志性SIGMA论文,还需要几年的时间。 TLS是90年代的密码:它当时意味着很好,看起来很酷,但是现代密码学家的调色板已经发展得不同了。

许多设计缺陷是使用形式验证发现的。 学者们试图证明TLS的某些安全属性,但却找到了反例,这些反例被转化为真正的漏洞。 这些弱点包括纯理论(SLOTH和CurveSwap),高资源攻击者(WeakDH,LogJam,FREAK,SWEET32),既“实用”又“危险”(POODLE,ROBOT)。

TLS 1.2实在是太慢了

加密在网上一直很重要,但从历史上看,它只用于登录或发送信用卡信息,使大多数其他数据暴露。 在过去几年中,一直存在一个主要趋势,即将HTTPS用于互联网上的所有流量。虽然能够保护更多我们在线上的交互,但却使连接变得更慢了。

要使浏览器和Web服务器就密钥达成一致,他们需要交换加密数据。 自TLS于1999年标准化以来,在TLS中称为“握手”的交换基本保持不变。握手需要在发送加密数据之前在浏览器和服务器之间再进行两次往返(或者在恢复先前连接时进行一次往返))。 与单独的HTTP相比,HTTPS的TLS握手的额外成本导致潜在的显着命中。 这种额外的延迟会对以性能为中心的应用产生负面影响。

定义TLS 1.3

IETF对TLS 1.2的过时设计和两次往返开销不满意,开始着手定义新版本的TLS。 2013年8月,Eric Rescorla为新协议制定了一份功能愿望清单:

https://www.ietf.org/proceedings/87/slides/slides-87-tls-5.pdf

经过一番辩论后,决定将这个新版本的TLS称为TLS 1.3。 推动TLS 1.3设计的主要问题与五年前提出的主要问题大致相同:

  • 减少握手延迟
  • 加密更多的握手
  • 提高跨协议攻击的弹性
  • 删除旧功能

该规范由志愿者通过开放的设计过程塑造,经过四年的勤奋工作和激烈的辩论,TLS 1.3现在处于最终形式:RFC 8446.随着采用的增加,新协议将使互联网更快、更安全。

下文将重点介绍TLS 1.3与以前版本相比的两个主要优势:安全性和性能。


在过去的二十年中,我们已经学到了很多关于如何编写安全加密协议的知识。 从POODLE到Lucky13到SLOTH到LogJam的巧妙命名攻击表明了,即使是TLS 1.2也包含了加密设计早期的陈旧观点。 TLS 1.3的设计目标之一是通过消除潜在危险的设计元素来纠正以前的错误。

修复密钥交换

TLS是所谓的“混合”密码系统。这意味着它使用对称密钥加密(加密和解密密钥相同)和公钥加密(加密和解密密钥不同)。混合方案是Internet上使用的主要加密形式,用于SSH,IPsec,Signal,WireGuard和其他协议。在混合密码系统中,公钥密码术用于在双方之间建立共享密钥,共享密钥用于创建可用于加密交换数据的对称密钥。

根据经验,公钥加密是缓慢且昂贵的(每个操作几微秒到几毫秒),对称密钥加密快速且便宜(每个操作纳秒)。混合加密方案允许您通过仅执行一次昂贵的部分,以极少的开销发送大量加密数据。 TLS 1.3中的大部分工作都是关于改进握手的部分,其中公钥用于建立对称密钥。

RSA密钥交换

TLS的公钥部分是关于建立共享秘密。 使用公钥加密有两种主要方法。 更简单的方法是使用公钥加密:一方用另一方的公钥加密共享密钥并发送它。 然后另一方使用其私钥解密共享秘密并且......原来他们都有同样的秘密。 这种技术于1977年由Rivest,Shamir和Adelman发现,称为RSA密钥交换。 在TLS的RSA密钥交换中,共享密钥由客户端决定,然后客户端将其加密到服务器的公钥(从证书中提取)并将其发送到服务器。

TLS中提供的另一种密钥交换形式是基于另一种形式的公钥密码术,由Diffie和Hellman于1976年发明,即所谓的Diffie-Hellman密钥协议。 在Diffie-Hellman中,客户端和服务器都从创建公钥 - 私钥对开始。 然后,他们将其关键份额的公共部分发送给另一方。 当每一方收到另一方的公钥共享时,他们将其与他们自己的私钥组合在一起,最终得到相同的值:前主秘密。 然后,服务器使用数字签名来确保交换未被篡改。 如果客户端和服务器都为每个交换选择一个新的密钥对,则该密钥交换称为“临时交换”。

两种模式都会导致客户端和服务器具有共享密钥,但RSA模式有一个严重的缺点:它不是前瞻性的。这意味着如果有人记录加密的对话,然后获得服务器的RSA私钥,他们就可以解密对话。这甚至适用于记录对话并且密钥在未来一段时间内获得的情况。在一个国家政府正在记录加密对话并使用像Heartbleed这样的漏洞来窃取私钥的世界中,这是一个相当现实的威胁。

RSA密钥交换在一段时间内一直存在问题,且不仅仅是因为它不是前向保密的。1998年,Daniel Bleichenbacher在SSL中进行RSA加密的方式发现了一个漏洞并创建了所谓的“百万消息攻击”,它允许攻击者通过发送一百万或者一个服务器的私钥来执行RSA私钥操作。 如此精心设计的消息,并寻找返回的错误代码的差异。 多年来,这种攻击得到了改进,在某些情况下只需要数千条消息便能从一台普通笔记本电脑发动攻击。最近发现,主要网站(包括facebook.com)在2017年也容易受到Bleichenbacher攻击变种的影响,称为ROBOT攻击。

为了降低非前向秘密连接和百万邮件攻击所带来的风险,RSA加密已从TLS 1.3中删除,将短暂的Diffie-Hellman作为唯一的密钥交换机制。 删除RSA密钥交换带来了其他优势,我们将在下面的性能部分中讨论。

以Diffie-Hellman命名的加密手段

在加密方面,提供太多选项会导致选择错误的选项。 在选择Diffie-Hellman参数时,这个原理最为明显。 在以前版本的TLS中,Diffie-Hellman参数的选择取决于参与者。 这导致一些实现选择不正确,导致部署易受攻击的实现。 TLS 1.3取消了这一选择。

Diffie-Hellman是一个功能强大的工具,但并非所有Diffie-Hellman参数都可以“安全”使用。 Diffie-Hellman的安全性取决于称为离散对数问题的特定数学问题的难度。 如果可以解决一组参数的离散对数问题,则可以提取私钥并破坏协议的安全性。 一般来说,使用的数字越大,解决离散对数问题就越困难。 因此,如果您选择较小的DH参数,则会遇到麻烦。

2015年的LogJam和WeakDH攻击表明,许多TLS服务器可能被欺骗使用Diffie-Hellman的小数字,允许攻击者破坏协议的安全性并解密对话。

Diffie-Hellman还要求参数具有某些其他数学属性。 2016年,Antonio Sanso在OpenSSL中发现了一个问题,其中选择的参数缺乏正确的数学属性,导致另一个漏洞。

TLS 1.3采用固定路由,将Diffie-Hellman参数限制为已知安全的参数。 但是,它仍然有几个选择; 只允许一个选项使得在以后发现这些参数不安全的情况下更新TLS非常困难。

混合加密方案的另一半是数据的实际加密。 这是通过组合认证码和对称密码来完成的,每个参与方都知道密钥。 正如我将要描述的,有许多方法可以加密数据,其中大多数都是错误的。

CBC模式密码

在上一节中,我们将TLS描述为混合加密方案,具有公钥部分和对称密钥部分。 公钥部分并不是多年来造成麻烦的唯一部分。 对称关键部分也有其公平的问题。 在任何安全通信方案中,您都需要加密(保密)和完整性(以确保人们不会修改,添加或删除对话的部分)。 对称密钥加密用于提供加密和完整性,但在TLS 1.2及更早版本中,这两个部分以错误的方式组合,导致安全漏洞。

执行对称加密和解密的算法称为对称密码。 对称密码通常有两种主要形式:分组密码和流密码。

流密码采用固定大小的密钥并使用它来创建任意长度的伪随机数据流,称为密钥流。 要使用流密码进行加密,您可以通过将密钥流的每个位与消息的相应位进行异或来获取消息并将其与密钥流合并。要解密,请使用加密消息并使用密钥流对其进行异或。 纯流密码的示例是RC4和ChaCha20。 流密码很受欢迎,因为它们易于实现且软件速度快。

分组密码与流密码不同,因为它只加密固定大小的消息。 如果要加密比块大小更短或更长的消息,则必须执行一些操作。 对于较短的消息,您必须在消息的末尾添加一些额外的数据。 对于较长的消息,您可以将消息拆分为密码可以加密的块,然后使用分组密码模式以某种方式将各个部分组合在一起。 或者,您可以通过使用块密码加密计数器序列并将其用作流来将块密码转换为流密码。 这称为“计数器模式”。 使用分组密码加密任意长度数据的一种流行方式是称为密码块链接(CBC)的模式。

为了防止人们篡改数据,加密是不够的。 数据还需要受到完整性保护。 对于CBC模式密码,这是使用称为消息验证代码(MAC)的东西来完成的,这类似于带有密钥的花哨校验和。 密码强的MAC具有以下特性:除非您知道密钥,否则找到与输入匹配的MAC值几乎是不可能的。 有两种方法可以组合MAC和CBC模式密码。 您先加密,然后加密密文,或者首先MAC明文,然后加密整个文件。 在TLS中,他们选择后者,MAC-then-Encrypt,结果证明是错误的选择。

你可以将这个选择归咎于BEAST,以及一系列填充oracle漏洞,例如Lucky 13和Lucky Microseconds。CBC模式和填充之间的交互也是SSLv3中广泛宣传的POODLE漏洞和TLS的一些实现的原因。

RC4是由Ron Rivest(RSA的“R”)设计的经典流密码,自TLS早期就得到广泛支持。 在2013年,它被发现具有可衡量的偏差,可以利用它来允许攻击者解密消息。

在TLS 1.3,所有麻烦的密码和密码模式已被删除。 您不能再使用CBC模式密码或不安全的流密码,如RC4。 TLS 1.3中允许的唯一类型的对称加密是一种称为AEAD(带有附加数据的经过身份验证的加密)的新结构,它将加密和完整性结合到一个无缝操作中。

修复数字签名

TLS的另一个重要部分是身份验证。 在每个连接中,服务器使用具有公钥的数字证书向客户端验证自身。 在RSA加密模式中,服务器通过解密预主密钥并在会话的记录上计算MAC来证明其对私钥的所有权。 在Diffie-Hellman模式下,服务器使用数字签名证明私钥的所有权。 如果你到目前为止都读得很仔细,应该很容易猜到这也是错误的。

PKCS#1v1.5

Daniel Bleichenbacher致力于识别TLS中RSA的问题。 2006年,他设计了针对TLS中使用的RSA签名的纸笔攻击。 后来发现包括NSS和OpenSSL在内的主要TLS实施容易受到这种攻击。 此问题再次与正确实现填充的难度有关,在这种情况下,RSA签名中使用的PKCS#1 v1.5填充。 在TLS 1.3中,删除了PKCS#1 v1.5以支持更新的设计RSA-PSS。

签署整个握手记录

我们之前描述过服务器如何使用数字签名来证明密钥交换没有被篡改。 在TLS 1.2及更早版本中,服务器的签名仅涵盖部分握手。 握手的其他部分,特别是用于协商使用哪个对称密码的部分,不由私钥签名。 相反,使用对称MAC来确保握手未被篡改。 这种疏忽导致了许多备受瞩目的漏洞(FREAK,LogJam等)。 在TLS 1.3中,这些被阻止,因为服务器签署整个握手记录。

FREAK,LogJam和CurveSwap攻击利用了两件事:

  1. 许多浏览器和服务器仍然支持20世纪90年代故意弱密码(称为导出密码)的事实,
  2. 以及用于协商使用哪种密码的握手部分未经数字签名的事实。

这些攻击被称为降级攻击,它们允许攻击者强制两个参与者使用双方支持的最弱密码,即使支持更安全的密码也是如此。 在这种攻击方式中,犯罪者处于握手的中间,并将从客户端通告的服务器支持的密码列表更改为仅包含弱导出密码。 然后,服务器选择一个弱密码,攻击者通过暴力攻击计算出密钥,允许攻击者在握手时伪造MAC。 在TLS 1.3中,这种类型的降级攻击是不可能的,因为服务器现在签署了整个握手,包括密码协商。

用简化来改善性能

TLS 1.3是一个更加优雅和安全的协议,删除了上面列出的不安全功能。 这种对冲修剪允许简化协议,使其更容易理解,更快。

在以前版本的TLS中,主要的协商机制是密码组。 密码套件几乎涵盖了可以就连接进行协商的所有内容:

  • 支持的证书类型
  • 用于导出密钥的散列函数(例如,SHA1,SHA256,...)
  • MAC功能(例如,HMAC与SHA1,SHA256,...)
  • 密钥交换算法(例如,RSA,ECDHE,......)
  • 密码(例如,AES,RC4,......)
  • 密码模式(如果适用)(例如,CBC)

先前版本的TLS中的密码套已经发展成为巨大的字母汤。 常用密码套件的示例是:DHE-RC4-MD5或ECDHE-ECDSA-AES-GCM-SHA256。 每个密码套件由一个名为Internet Assigned Numbers Authority(IANA)的组织维护的表中的代码点表示。 每次引入新密码时,都需要将一组新的组合添加到列表中。 这导致代码点的组合爆炸,代表着参数的每一个有效选择。

TLS 1.3删除了许多这些遗留功能,允许在三个正交协商之间进行彻底拆分:

  • 密码+ HKDF哈希
  • 密钥交换
  • 签名算法

这种简化的密码套件协商和从根本上减少的协商参数集开辟了一种新的可能性。 这种可能性使得TLS 1.3握手延迟从两次往返降至仅一次往返,从而提供性能提升,确保TLS 1.3受欢迎并广泛采用。


建立与之前没有见过的服务器的新连接时,需要两次往返才能在连接上发送数据。 这在服务器和客户端在地理位置上彼此靠近的位置并不是特别明显,但是它可以在移动网络上产生很大的差异,其中延迟可以高达200ms,这对人来说是显而易见的。

1-RTT模式

TLS 1.3现在具有更简单的密码协商模型和一组减少的密钥协商选项(没有RSA,没有用户定义的DH参数)。 这意味着每个连接都将使用基于DH的密钥协议,并且服务器支持的参数很容易猜测(ECDHE使用X25519或P-256)。 由于这种有限的选择,客户端可以简单地选择在第一条消息中发送DH密钥共享,而不是等到服务器确认它愿意支持哪些密钥共享。 这样,服务器可以学习共享密钥并提前一次往返发送加密数据。 例如,Chrome的TLS 1.3实现会在第一条消息中向服务器发送X25519密钥共享。

在极少数情况下,服务器不支持客户端发送的密钥共享之一,服务器可以发送新消 HelloRetryRequest,让客户端知道它支持哪些组。 由于列表已被削减太多,预计这种情况不常发生。

0-RTT恢复

QUIC协议启发了进一步的优化。 它允许客户端将第一条消息中的加密数据发送到服务器,与未加密的HTTP相比,不会产生额外的延迟成本。 这是一大进步,一旦TLS 1.3被广泛部署,加密的网络肯定比以前更加快捷。

在TLS 1.2中,有两种方法可以恢复连接,会话ID和会话票证。 在TLS 1.3中,这些被组合以形成称为PSK(预共享密钥)恢复的新模式。 该想法是在建立会话之后,客户端和服务器可以导出称为“恢复主密钥”的共享秘密。 这可以使用id(会话ID样式)存储在服务器上,也可以通过仅为服务器知道的密钥(会话票据样式)加密。 此会话票证将发送到客户端并在恢复连接时进行兑换。

对于恢复的连接,双方共享恢复主密钥,因此除了提供前向保密之外,不需要密钥交换。 下次客户端连接到服务器时,它可以从上一个会话中获取秘密并使用它来加密应用程序数据以及会话票证发送到服务器。

0-RTT数据中没有交互性。 它由客户端发送,并由服务器使用,没有任何交互。 这对性能很有帮助,但需要付出代价:可重复性。 如果攻击者捕获发送到服务器的0-RTT数据包,他们可以重播它,并且服务器有可能接受它为有效。 这会产生有趣的负面后果。

危险重放数据的一个示例是在服务器上更改状态的任何内容。 如果增加计数器,执行数据库事务或执行任何具有永久效果的操作,将其放入0-RTT数据中是有风险的。

作为客户端,您可以尝试通过仅将“安全”请求放入0-RTT数据来防止这种情况。 在此上下文中,“安全”表示请求不会更改服务器状态。 在HTTP中,不同的方法应该具有不同的语义。 HTTP GET请求应该是安全的,因此浏览器通常只能通过在0-RTT中发送GET请求来保护HTTPS服务器免受重放攻击。 由于大多数页面加载以GET“/”开头,因此页面加载时间更快。

当在0-RTT中发送的数据用于状态改变请求时,问题开始发生。 为帮助防止此故障情况,TLS 1.3还包括会话票证中的经过时间值。 如果这种情况发生太大分歧,客户端要么接近光速,要么重播值。 在任何一种情况下,服务器都应该谨慎拒绝0-RTT数据。

可部署性

TLS 1.3与TLS 1.2及更早版本完全不同,但为了广泛部署,它必须向后兼容现有软件。 TLS 1.3从草案到最终发布花了这么长时间的原因之一是,一些现有的软件(即中间盒)与新的更改并没有很好地协调。 即使在线上可见的TLS 1.3协议的微小更改(例如消除冗余的ChangeCipherSpec消息,将版本从0x0303提升到0x0304)最终导致某些人的连接问题。

尽管未来的灵活性已经内置到TLS规范中,但是一些实现对如何处理未来的TLS版本做出了错误的假设。造成这种变化的现象称为骨化, 为了适应这些变化,TLS 1.3被修改为看起来很像TLS 1.2会话恢复(至少在线路上)。 这导致了更多功能性但不太美观的协议,也是您在线升级最广泛部署的协议之一所付出的代价。

结语

TLS 1.3是一种现代安全协议,使用正式分析等现代工具构建,保持其向后兼容性。 它已经过广泛测试,并在使用现实世界部署数据时进行了迭代。 它是一种更清晰,更快速,更安全的协议,可以在线成为事实上的双方加密协议。

发布TLS 1.3是一项巨大的成就。也是近日行业里最好的示例,它证明了通过修改20年前部署的遗留代码来改善人们互联网体验,是一件多么棒的事!TLS 1.3在过去三年中一直处于争论和分析中,现在已准备好迎接它的黄金时段。 欢迎你,RFC 8446!

 

稿源:Cloudflare博客

七月行业新闻回顾

Jesdoit阅读(588)评论(0)

Chrome对所有HTTP网页说“不安全”

在最新发布的Chrome68中,谷歌Chrome浏览器引入了对全网非HTTPS页面的警告。“不安全”标记出现在所有使用HTTP加载的页面的左上角地址栏。

这一举动在今年2月被提出,时至今日才正式被采用。谷歌旨在让HTTPS成为网络的标准并最终希望去除安全指示锁。目前,该警告仍处于最温和的版本。 未来的版本可能包含一个红色警告标志,正如谷歌之前所解释的那样。

在Chrome默认启用警告的那天,安全研究人员Troy Hunt和Scott Helme启动了为什么没有HTTPS? 项目,列出了尚未默认为HTTPS的流行网页,也可以按国家/地区显示它们。 不受HTTPS限制的最受欢迎的页面是中文搜索引擎百度; 列表中最受欢迎的非中文页面是Twitter的URL缩短服务,t.co.

本月短新闻

稿源:FeistyDuck