en English
X

Select Language

Powered by Google TranslateTranslate

We hope you will find the Google translation service helpful, but we don’t promise that Google’s translation will be accurate or complete. You should not rely on Google’s translation. English is the official language of our site.

en English
X

Select Language

Powered by Google TranslateTranslate

We hope you will find the Google translation service helpful, but we don’t promise that Google’s translation will be accurate or complete. You should not rely on Google’s translation. English is the official language of our site.

TLS 1.3在这里停留

世界正在走向 TLS 1.3,这是非常好的事情! 本文提供了以下方面的高级概述 TLS 1.3,并讨论其新功能的有效性。

传输层安全性

传输层安全性,或 TLS,是一种加密协议,用于保护通过计算机网络交换的数据。 TLS 已成为著名的 S in HTTPS。 进一步来说, TLS 用于保护Web用户数据免受网络攻击。

TLS 被设计为比其前身更安全的选择 安全套接字层 (SSL)。 多年来,安全研究人员发现了影响SSL的大量漏洞,这促使IETF进行了设计 TLS 为了减轻他们的负担。

具有讽刺意味的是, TLS 也受到危险漏洞的影响,最终导致 TLS 1.2(即行业专家推荐的默认版本)。

大多数已知协议漏洞已在 TLS 1.2,但是这种安全级别仍然是有缺陷的设计之上的一系列补丁的结果。

作为回应, TLS 1.3是从头开始起草的,旨在简洁地设计出现代且安全的产品 TLS 协议。 经过五年的测试,它终于获得批准,现在已接近默认的Internet安全标准。

TLS 版本和各自的RFC文档可在以下列表中找到:

怎么老 TLS 版本有效吗?

有效讨论 TLS 1.3,首先要谈几岁 TLS 版本有效(以及如何无效)。

TLS 混合 加密系统,这意味着它同时使用 非对称 (公钥)和 对称 (基于密码/短语)加密。 这是因为 非对称密码学 比其对称等价物慢几个数量级。

所以, TLS 仅使用公共密钥,以便客户端和服务器可以安全地交换对称密钥。 然后,可以使用此密钥对所有后续通信进行加密,从而避免了非对称加密带来的性能开销。

TLS 1.2支持多种密钥交换算法(例如RSA,DH等)以及几种算法(也称为 密码)用于加密和解密邮件。 大量的替代选项需要客户端和服务器进行协商,以便各方使用相同的 TLS 参数。

此协商在称为的协议中标准化 握手。 如果您不熟悉,请参阅 本文 获取更多信息.

那怎么了 TLS 1.2?

尽管 TLS 事实证明1.2在大多数情况下都可以正常工作,但经过多年的修补和修订后,人们对它提供的整体安全性和隐私级别感到担忧。

除了安全方面的考虑, TLS 1.2还带来不必要的性能和网络开销。

TLS 1.2安全问题

多年来,研究人员(和攻击者)在许多地方发现了许多漏洞 TLS 1.2组件,包括密钥交换算法,密码和数字签名。 其中一些是您可能听说过的实现错误,例如 心脏出血漏洞 or BERSERK。 但是,有些是协议漏洞–也就是说,它们在较早的时候就利用了错误的设计决策 TLS 版本(即之前 TLS 1.2)。

尽管大多数实现和其他错误已修复 TLS 1.2,不幸的是,仅使用软件补丁无法修复协议设计中的漏洞。 事实证明,要做到这一点,IETF必须完全重新设计握手协议。 TLS 1.3.

有很多关于 TLS 安全性,但最有影响力的一项是意识到 TLS 1.2(以及所有早期版本,包括SSL)由于其握手协议设计中的缺陷而容易受到降级攻击。 进一步来说, TLS 1.2不使用数字签名来保护握手的完整性。 仅在密码套件协商之后,签名才保护部分握手。

因此,攻击者可以操纵在同一计算机网络(例如,机场wifi)中发生的任何第三方密码套件协商,并强制使用不安全的密码。 然后,他们可以破坏该易受攻击的密码,并获得不必要的访问整个对话的权限。

TLS 1.2性能问题

除了这些安全方面的考虑, TLS 1.2需要协商众多 TLS 参数可能会对HTTPS(或其他 TLS 受保护的)通信。

TLS 1.2的4步握手需要两次往返交换,首先选择密码套件,然后交换证书和对称密钥(或密钥共享)。

这意味着对于每个 TLS 建立连接, 另外两笔交易 与服务器是必需的。 结果是, TLS 连接需要比(未加密的)HTTP更多的带宽和功率,这对于物联网(IoT)应用程序而言尤其昂贵,因为在物联网应用程序中,低功耗和带宽消耗是严格的限制。

TLS 1.2隐私问题

最后, TLS 有人批评1.2损害了Web用户的隐私。

进一步来说, TLS 提供称为 服务器名称指示 或SNI。 SNI允许将服务器的主机名包含在初始SSL握手中。 此扩展用于虚拟主机,其中服务器可以在同一IP地址和端口上服务多个域,同时为每个域提供不同的证书。

In TLS 1.2,发送SNI 加密,因此尽管使用了HTTPS,网络攻击者仍可以泄漏此信息并跟踪用户访问的网页。

如何 TLS 1.3修复所有问题?

TLS 1.2(及更早版本)专注于保持向后兼容性。 每个版本都建立在先前版本的基础上,并进行了较小的修订,试图消除之间发布的漏洞 TLS 版本。

遗憾的是,这还意味着较差的协议设计决策(例如,未保护的握手)也继承于较新的版本。

TLS 1.3放弃了向后兼容性,而是采用了适当的安全设计。 它是从头开始设计的,旨在提供与(但不兼容)相似的功能 TLS 1.2,但性能,隐私和安全性得到了显着改善。

TLS 1.3安全性

的核心宗旨 TLS 1.3是简单。 在新版本中,除 的Diffie-Hellman (DH)密钥交换,已删除。 TLS 1.3还定义了一组经过测试的DH参数,从而无需与服务器协商参数。

更重要的是, TLS 1.3不再支持不必要的或易受攻击的密码,例如CBC模式和RC4密码。 众所周知,这些密码容易受到攻击,但在大多数情况下仍受支持 TLS 实现旧版兼容性。 幸运的是,最近出现的降级攻击热潮影响了早期 TLS 版本激励IETF完全从中删除此类密码 TLS 1.3.

此外, TLS 1.3要求服务器对整个握手(包括密码协商)进行加密签名,以防止攻击者修改任何握手参数。 这意味着 TLS 1.3在架构上不受先前影响的降级攻击的影响 TLS 版本。

最后,签名本身也通过实施称为 RSA-PSS。 RSA-PSS签名不受密码攻击的影响,这会影响早期使用的签名方案 TLS 版本。

TLS 没有表现

除了提高安全性外,减少了参数集并简化了握手过程。 TLS 1.3还有助于提高整体性能。 由于只有一种密钥交换算法(带有内置参数)和少数支持的密码,因此设置密钥交换所需的绝对带宽 TLS 1.3通道比早期版本要少得多。

此外, TLS 1.3现在支持一种新的握手协议,称为 1-RTT模式。 在1-RTT中,客户端可以在第一个握手消息中发送DH密钥份额,因为它可以确定服务器将使用的参数。 在极少数情况下,服务器不支持它们,则可能会产生错误,以便客户端发送不同的配置。

与其先协商参数然后交换密钥或密钥份额,不如说是, TLS 1.3允许客户设置 TLS 通道只有一次往返事务(而不是以前的两次)。 这可能对客户端与服务器进行通信所需的处理,功能和网络资源产生巨大的累积影响。 TLS 1.3.

性能优化并不仅限于此 TLS 1.3功能,称为 0-RTT恢复模式。 当浏览器首次访问服务器并成功完成 TLS 握手时,客户端和服务器都可以在本地存储预共享的加密密钥。

如果浏览器再次访问服务器,则可以使用此恢复密钥将加密的应用程序数据的第一条消息发送到服务器。 这与未加密的HTTP具有相同的延迟,因为不需要初始握手。

应当指出,已经有一些安全性 关注 过去大约是0-RTT模式。

TLS 1.3隐私

从过去的错误中学习, TLS 1.3现在提供了 延期 加密SNI信息。 如果正确使用此扩展名,则可以防止攻击者泄漏远程服务器的域名,因此他们无法跟踪HTTPS用户历史记录。 与以前版本的相比,此功能为Internet用户提供了更大的隐私 TLS.

总结

而 TLS 这些年来,1.2一直是光荣的, TLS 事实证明1.3更安全有效。 TLS 1.3已经在实验性浏览器实现中进行了广泛的测试,现在可以替换了。 TLS 1.2作为网络安全协议的首选。 出版 TLS 1.3向所有人更快,更安全的互联网迈出了一大步。

感谢您选择SSL.com,我们相信 更安全 互联网是一个 更好 互联网上。

相关文章

订阅SSL.com的新闻通讯

什么是SSL /TLS?

播放视频

订阅SSL.com的新闻通讯

不要错过SSL.com上的新文章和更新