关注网络安全
和行业未来

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

hansen阅读(40)评论(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阅读(40)评论(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阅读(130)评论(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阅读(215)评论(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阅读(549)评论(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阅读(441)评论(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阅读(685)评论(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阅读(485)评论(0)

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

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

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

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

本月短新闻

稿源:FeistyDuck

通往QUIC之路

Jesdoit阅读(531)评论(1)

QUIC(快速UDP互联网连接)协议是一种新的默认加密的互联网通信协议,它提供了许多改进,旨在加速HTTP通信,同时使其变得更加安全,其最终目的是在web上代替TCP和TLS协议。在这篇博客中,我们将对QUIC协议的一些内容进行概述,这些内容包括该协议的一些关键特性以及这些特性会如何使web受益,还包括支持这种激进的新协议过程中遇到的一些挑战。

事实上,有两种协议共用这个名称,一种是“Google QUIC”(简称gQUIC),它是几年前由谷歌公司的工程师设计的原始协议,经过多年的试验,该协议现在已经被IETF(互联网工程任务组)采纳为标准协议。
另一种是“IETF QUIC”(从现在开始叫作“QUIC”),它已经与gQUIC有了很大的不同,以至于它可以被认为是一个单独的协议。从数据包的有线格式,到握手机制和HTTP的映射,通过许多机构和个人的开放的合作,QUIC协议改进了最初的gQUIC设计,实现了让互联网更快、更安全的共同目标。

那么,QUIC带来的改进是什么呢?

内置的安全性(以及性能)

QUIC有一个更彻底的背离现在脆弱的TCP协议的特点,即它所声称的设计目的是提供一个默认安全的传输协议。通过提供一些安全方面的特性,比如身份验证和加密等,QUIC协议自身实现了这一目的。而这些工作通常本应是由更高层次的协议(如TLS协议)来完成的。

最初的QUIC握手机制将TCP协议使用的典型的三次握手方式,与TLS1.3协议的握手机制结合起来,它提供了端点的身份验证以及加密参数的协商等机制。对于那些熟悉TLS协议的人们来说,QUIC用它自己的框架格式代替了TLS协议的记录层,同时保留了与原来相同的TLS握手消息。

这不仅能够确保连接总能实现身份验证和加密,而且,由此使得初始连接的建立速度更快了:相比于TCP和TLS1.3相结合的握手机制需要客户端和服务器之间两次消息往返来说,典型的QUIC握手只需要一次往返就可以完成。

基于TCP+TLS的HTTP请求:

基于QUIC的HTTP请求:

但是QUIC走得更远,它还对额外连接的元数据进行加密,这些元数据可能被一些中间件所利用,从而对连接产生干扰。例如,当连接迁移的漏洞被利用时,路途中的被动攻击者可以利用数据包编号来发现多条网络路径上的用户活动之间的联系(详见下文)。通过加密数据包编号,QUIC可以确保,除了通信连接的端点之外,没有任何实体能够使用数据包编号来发现用户活动之间的联系。

加密也可以是一种有效的避免僵化的补救措施。所谓僵化是指,由于在部署时作出了错误的假设,导致某种协议原本内置的调节机制(例如,原本该协议与其自身的几个版本之间都可以进行协商)实际上无法奏效(僵化正是这么长时间以来TLS1.3的部署仍然被拖延的原因,TLS1.3旨在防止僵化的中间件错误地阻止该协议的修正,而只有当该协议做出几项重要变更后,才可能被广泛部署)。

队首阻塞

HTTP/2所带来的主要改进之一是,它能够将不同的HTTP请求多路传输到同一个TCP连接上。这使得HTTP/2应用程序能够并发地处理请求,并更好地利用它们可用的网络带宽。

这比原来的情况有了很大的改进,当时的要求是,如果应用程序想要并发地处理多个HTTP/1.1请求(例如,当浏览器需要同时获取CSS和Javascript资源以呈现web页面时),就需要初始化多个TCP+TLS连接。创建新的连接需要多次重复最初的握手,同时还要经历最初的拥塞窗口缓慢增大的过程,这意味着web页面的呈现速度被减慢了。多路复用HTTP交换则避免了所有这些问题。

然而,这有一个缺点:由于多个请求/响应通过同一个TCP连接传输,它们都同样受到数据包丢失(例如,由于网络拥塞所造成的)的影响,即使丢失的数据只涉及单个请求。这被称为“队首阻塞”。

QUIC走得更远一些,它为多路复用提供一流的支持,这样,不同的HTTP流反过来可以映射到不同的QUIC通信流,然而,尽管它们仍然共享同一QUIC连接因而不需要额外的握手,而且拥塞状态也是共享的,但QUIC流的传输却是独立的,因此在大多数情况下,数据包丢失只影响一个通信流,而不会影响其他人。

这可以极大地减少所需的时间,例如,呈现完整的web页面(带有CSS、Javascript、图片以及其它类型的资源)的时间,特别是在通信需要跨越高度拥挤的网络并伴随着很高的丢包率的情况下。

真的就那么简单?

为了实现它的承诺,QUIC协议需要打破许多网络应用程序认为理所当然的一些假设,这可能会使QUIC的实现和部署变得更加困难。

QUIC被设计为在UDP数据报的顶端进行传输,这样可以简化部署,并避免来自网络设备的一些问题(一些网络设备会自动丢弃来自未知协议的数据包),这是因为大多数设备已经支持UDP协议。这也使得QUIC可以在用户那一端进行部署,例如,浏览器将能够实现新的协议功能,并将它们发送给用户,而不必等待操作系统的更新。

然而,尽管目标是避免连接受损,但它也给防范入侵以及如何正确地将数据包路由到正确的端点带来了更多的挑战。

一个NAT把它们都带了出来,然后在暗中把它们捆绑起来

典型的NAT路由器能够对通过自身的TCP连接进行追踪,这可以使用传统的四元组(源IP地址、源端口、目标IP地址、目标端口)来实现,而通过观察在网络中传输的TCP数据包中的SYN、ACK和FIN标记位,这些路由器可以检测到新连接的建立和终止。这使得它们能够精确地管理NAT绑定的生命周期、内部IP地址和端口之间的联系以及外部IP地址。

而对于QUIC来说,这现在还是不可能的,因为目前部署在外部网络的NAT路由器还并不了解QUIC,所以它们通常会退回到默认的和不太精确的UDP流处理机制,这通常涉及到使用任意长度(有时非常短)的超时,而这可能会影响那些长时间运行的连接。

当一个NAT重新绑定发生时(例如由于超时),位于NAT边界之外的通信端点会看到来自另一个源端口的数据包,该端口与连接最初建立时被观察到的源端口并不相同,这样,就不可能通过使用传统的四元组来追踪连接。

而且不仅仅是NAT!QUIC想要带来的特性之一是“连接迁移”,它将允许QUIC端点将连接任意地迁移到不同的IP地址和网络路径。例如,当一个已知的WiFi网络变得可用时(比如,当用户进入他们最喜欢的咖啡厅时),移动客户端将能够在蜂窝数据网络和WiFi网络之间迁移QUIC连接。

QUIC试图通过引入连接ID的概念来解决这个问题,连接ID是指,一个由QUIC数据包携带的,任意的,不透明的,可变长度的blob对象,它可以用来标识网络连接。终端可以使用这个ID来追踪它们所负责的连接,而不需要检查四元组(实际上,可能会有多个ID来标识相同的连接,例如,可以用来避免在连接迁移时连接到不同的路径,但这种行为是由终端而不是中间件来控制的)。

然而,这也给使用任意播寻址方式和ECMP路由的网络运营商带来了问题,在ECMP路由中,单个目标IP地址可能会指向数百台甚至数千台服务器。因为这些网络所使用的边缘路由器也还不知道如何处理QUIC通信,可能会发生这样的情况,属于同一QUIC连接(这指的是具有同一连接ID的QUIC连接)但却具有不同的四元组(这是由于NAT重新绑定或连接迁移所造成的)的UDP数据包可能会被路由到不同的服务器,从而最终导致连接断开。

为了解决这个问题,网络运营商可能需要使用更加智能的第四层负载均衡解决方案,这种解决方案可以在软件中实现,并且在不需要接触边缘路由器的情况下部署(例如,Facebook的Katran项目)。

QPACK

HTTP/2所带来的另一个好处就是头部压缩(或叫作HPACK),它使得HTTP/2端点可以通过删除HTTP请求和响应的冗余来减少通过网络传输的数据量。

特别是,相比其他各项技术,HPACK所使用的充满了从此前的HTTP请求(或响应)发送(或接收)的报头的动态表,使得端点可以在新的请求(或响应)中引用以前遇到过的头部信息,而不必再一次传输它们。

HPACK的动态表需要在编码器(发送HTTP请求或响应的一方)和解码器(接收它们的一方)之间进行同步,否则解码器将无法解码它接收到的内容。

基于TCP的HTTP/2的这种同步是透明的,因为传输层(TCP)负责以与报文被发送到该层时相同的顺序来传输HTTP请求和响应,对表进行更新的指令可以直接作为请求(或响应)本身的一部分,由解码器进行发送,这使编码变得非常简单。但对于QUIC来说,情况则更为复杂。

QUIC可以在不同的流中独立地传递多个HTTP请求(或响应),这意味着,虽然对于单个流而言,它可以按顺序传输数据,但在多个流当中,却无法保证正确的传输顺序。

例如,如果一个客户端在QUIC流A中发送HTTP请求A,然后在QUIC流B中发送请求B,那么,由于在网络中数据包会重新排序或丢失,因此可能会发生服务器在收到请求A之前就收到请求B的情况,而如果请求B被编码了因而需要参考请求A的头部信息,那么由于服务器还未收到请求A,它将无法解码请求B。

在gQUIC协议中,这个问题通过在gQUIC流中简单地对所有HTTP请求和响应的头部(而不是主体)进行序列化而得到了解决,这意味着无论如何都要按顺序传输头部。这是一个非常简单的方案,它使得程序可以重复使用大量现有的HTTP/2代码,但另一方面,它也增加了队首阻塞的情况,而这本来是QUIC设计时想要减少的。因此,IETF QUIC工作组设计了一个在HTTP和QUIC(“HTTP/QUIC”)之间的新映射关系,同时还设计出一个名为“QPACK”的新头部压缩方案。

在最新的HTTP/QUIC映射和QPACK规范草案中,每个HTTP请求/响应交换都使用它自己的双向QUIC流,因此就没有队首阻塞的情况。此外,为了支持QPACK,每个对等节点会创建两个额外的单向QUIC流,一个用于向另一个对等节点发送QPACK表更新,而另一个则用于确认另一方收到的更新。通过这种方式,一个QPACK编码器只能在被解码器明确地承认后才能使用动态表引用。

使反射攻击偏转方向

在基于UDP的一些协议中,一个常见的问题是,它们容易受到反射攻击。这种攻击是这样进行的,为了对目标主机进行攻击,攻击者假冒发往服务器的数据包的源IP地址,使得这些数据包看起来像是由目标主机发过来的,从而欺骗了服务器,这样,服务器就会误认为目标主机请求了大量数据,于是就会将这些数据发送过去。

当服务器发出的响应比它接收到的请求更大时,这种攻击可能是非常有效的,在这种情况下,我们讨论的是“放大”。

这种攻击通常不使用TCP连接,因为在握手过程中传输的初始数据包(SYN、SYN+ACK、……)具有相同的长度,因此它们不会有任何被放大的可能。

QUIC的握手方式则是非常不对称的:就像对于TLS一样,在它的第一次旅程中,QUIC服务器通常会发送自己的证书链,它可能非常大,而客户端则只需要发送几个字节(将TLS的客户端问候消息嵌入到QUIC包中)。基于这个原因,客户端发送的初始QUIC包必须被填充到特定的最小长度(即使包的实际内容要小得多)。然而,这种缓和措施仍然是不够的,因为典型的服务器响应会跨越多个数据包,因此仍然比填充的客户端数据包大得多。

QUIC协议还定义了一个显式的源地址验证机制,在这种机制中,服务器只发送一个小得多的“重试”数据包,而不会发送较长的响应。这个小的数据包包含一个唯一的加密令牌,然后,客户端将必须在一个新的初始数据包中对服务器进行响应。通过这种方式,服务器将会更加信任客户端,相信客户端并未使用假冒的源IP地址(这是因为客户端收到了重试数据包),这样就可以完成握手了。这种缓和措施的缺点是,它增加了最初的握手时间,从一次往返变成了两次往返。

另一种可选的解决方案是,减少服务器的响应,使得反射攻击变得不那么高效,例如,使用ECDSA证书(这种证书通常比使用RSA算法的证书要小得多)。我们也一直在试验一种使用现成的压缩算法(如zlib和brotli)来压缩TLS证书的机制,这种机制最初是由gQUIC引入的一种功能,但目前还没有在TLS中使用。

UDP的性能

QUIC的一个反复出现的问题在于,部署在外部网络的现有硬件和软件无法理解它。我们已经研究了QUIC如何试图解决像路由器这样的网络中间件的问题,但是,另一个潜在的问题是,在QUIC端点上使用UDP协议发送和接收数据的性能如何。多年以来,人们做了很多工作来尽可能地优化TCP应用,包括在软件(如操作系统)和硬件(如网络接口)上建立卸载功能,但是目前UDP协议还不支持这些功能。

然而,QUIC应用可以使用这些功能将只是个时间问题。例如,最近人们致力于在Linux系统中为UDP协议实现通用分段卸载(Generic Segmentation Offloading)功能,这将使应用程序可以在用户空间和内核空间的网络协议栈之间以一个UDP段(或非常接近)的开销捆绑传输多个UDP段,以及为Linux加入零复制套接字支持的UDP段,这可以使应用程序免去从用户空间向内核空间复制信息的开销。

结语

与HTTP/2和TLS1.3一样,QUIC将提供许多新的特性,以提高web站点的性能和安全性,它也会提供许多其它的基于互联网的属性。IETF工作组计划于今年年底前交付QUIC规范的第一个版本,让我们拭目以待!

稿源:Cloudflare blog

Apple将于7月20日停止信任非CT登录的SSL / TLS证书

Jesdoit阅读(429)评论(0)

该公告是苹果公司赛门铁克CA不信任计划的补充

苹果公司已经明确了赛门铁克CA不信任计划,其中有即将到来的7月20日的最后期限。 2016年6月1日至2017年12月1日期间签发的任何Symantec CA SSL证书如果未发布到证书透明度日志,将不受信任。

这仅适用于Symantec CA证书,对于SSL / TLS生态系统的其余部分,Apple的CT截止日期仍为10月15日。除了浏览器中的Web内容之外,该要求不会影响SSL / TLS用例。 受影响的申请将包括:

  • macOS High Sierra
  • macOS应用程序
  • iOS 11
  • iOS应用
  • Safari浏览器

这不太可能产生重大影响,因为不信任将主要影响已经被谷歌Chrome浏览器和Mozilla Firefox处罚的证书。 此外,赛门铁克此前与谷歌的混战之后,已经要求记录它发布的证书了。

尽管如此,网站所有者仍希望仔细检查他们的Symantec CA SSL证书,以免他们被四大网络浏览器之一取消信任。

如何判断我的SSL证书是否已经过CT记录?

证书透明度是一个行业的事情,最终用户无需做任何事情来记录自己的证书。 CA必须这样做。 但是,有两种方法可以检查并查看是否已记录您颁发的SSL证书。 第一种方法是检查浏览器中的证书详细信息。

  1. 访问你的网站
  2. 单击浏览器地址栏中的挂锁图标
  3. 查找可以查看证书或证书详细信息的位置
  4. 查找字符串:'1.3.6.1.4.1.11129.2.4.2'

如果找到它,则表示您的证书已被记录。 所有CT记录的证书的OID都相同。 现在,浏览器以不同的方式显示此信息。 例如,Safari将其显示为:

Firefox将其称为对象标识符。

Google会让您浏览其菜单,从“更多工具”部分选择开发人员工具,然后导航到安全性,您可以通过单击“主要来源”查看证书详细信息。

如果您正在使用Microsoft Edge,或者只是不想在浏览器中点击,还有另一种方法可以检查。 您还可以使用Symantec的CryptoReport:

转到Symantec CryptoReport。
输入您的网址。
检查:“Certificate Transparency: Embedded in certificate”(证书透明度:嵌入证书)
如果该行存在,则说明已录入CT!

如果不是,并且您使用的是2016年6月1日至2017年12月1日期间颁发的Symantec CA品牌SSL证书,则需要立即重新颁发或更换您的SSL证书。 您的替代品将来自DigiCert,后者现已收购赛门铁克CA,并在过去9个月中一直在努力更换数百万受影响的证书。

稿源:The ssl store