首页 / 科技 / 关于TLS 1.2以及TLS 1.3的部署,安全漏洞,功能差异TLS 1.3核心概论

关于TLS 1.2以及TLS 1.3的部署,安全漏洞,功能差异TLS 1.3核心概论

TLS(正式的英文全称是-The Transport Layer Security (TLS) Protocol)加密是我们经常看到的关于传输层加密的主要支持加密方式。目前,在市场上仍然有部分网络产品和网站使用TSL 1.1版本,也有用户使用TLS 1.2版本,仅小部分用户开始使用TLS 1.3。TLS 1.2版本已经使用多年,但是最近几年针对安全问题和TSL漏洞的问题频发,AWS和红帽子都发布过关于TLS漏洞的声明。

针对TLS的安全漏洞和握手性能处理诟病等问题,TLS发布了最新的TLS 1.3版本。此版本无论从TLS交互的性能和安全方面都有了很大的改善。我们可以预知,可能最近几年,包括在未来几年的部署环境中,越来越多的用户会部署TLS 1.3。为了让用户能够提前学习和了解关于TLS 1.3的性能优化以及握手机制,参数设置,算法的提升等核心内容。笔者专门重点针对TLS 1.3的规范,和大家分享关于TLS-1.2的背景知识,版本之间的差异,TLS 1.3 版本重大升级,RFC8446规范的概论以及TLS 1.3 不同内核环境的性能和其他技术通知进行讨论。

声明:以下文章中所引用的图例和部分其他说明均来自于互联网资源。本人水平和精力有限,文章中可能存在某些错误,请读者谅解!如果读者想了解更多关于TLS加密和一些重要研究成果,请访问文章的参考资料部分的资源链接。

关于TLS版本的背景说明

关于TLS的非常基础大背景知识,笔者不打算展开篇幅进行讨论,读者可以参考笔者的历史文档来进行学习。

完整SIP网络技术系列讲座-SIP安全-RTP加密,TLS使用,SRTP讨论

自从TLS 12.版本(RFC5246)2008年发布以来,目前,很多公司的产品仍然使用TLS 1.2。前几年网络上也爆出了很多的安全漏洞。另外,TLS 1.2的性能也是很多人诟病的地方。支持更安全高效的TLS版本是迫在眉睫的事情,同时也逐渐提到了产品更新的日程上来了。我们大概了解一下关于TLS的发布里程碑,以下是关于各种TLS版本的列表:

此图例以及以下图例均来自于互联网资源

以下是关于各个TLS版本的对应的RFC规范和生命周期:

我们现在了解关于TLS 版本的使用状态。2020年,一家安全权威机构对100个健康护理的网站关于使用SSL/TLS的调查发现,绝大部分的网站仍然使用着比较旧的TLS版本,使用的比较弱的密码保护:

另外一家安全网络咨询公司GIAC的2021年的调查数据表明,在商业领域客户中,绝大部分的用户仍然使用TLS 1.2。

笔者也曾经发表过一篇关于VoIP行业安全的文章讨论了关于SIP终端和服务器端的安全的问题。读者可以查阅参考:谁的SIP软交换呼叫中心终端摄像头正在公网裸奔

根据 Gigamon发布的关于2022 TLS TRENDS RESEARCH 的研究报告指出,TLS 1.3在2018年发布以后,大约20%的企业网络流量使用了TLS 1.3, 很多企业仍然使用TLS 1.2和其他历史版本。目前每月使用占比,TLS 1.2几乎占据了接近80%的用户流量,TLS的使用率为18%。但是,我们可以看到的一个趋势是TLS 1.3 的使用量正在逐步增加,而TLS 1.2 的使用量却在下降。

看来用户是最聪明的。我们根据这个使用趋势就大概可以判断出TLS 1.3 是未来TLS传输加密版本的主要版本。那么,为什么这么多用户开始选择TLS 1.3 而开始抛弃TLS 1.2呢?安全性和性能表现是用户抛弃TLS 1.2的最主要的原因。接下来,我们讨论一下和TLS 1.2 相比,TLS 1.3所具备的一些优势。

关于TLS-1.2和1.3 的主要区别

关于TLS 1.2和TLS 1.3,两者之间有着很大的不同。简单来说,和TLS 1.2 相比, TLS 1.3 具备以下五大优势:

    减少了 round-trip 处理流程,快速握手机制降低了协商周期时间因为高效的快速握手机制带来的协商时间缩短,优化了网络时延因为握手时延的降低,增加了用户网站访问的体验效果完善了抵御跨协议攻击的弹性处理机制移除了一些旧版本的带安全漏洞的加密算法

综合以上五个关于TLS 1.3 的优势,我们再具体说明其更新情况。首先,从基本的安全机制和算法方面,TLS 1.3 果断废弃了带安全漏洞的加密算法,移除了一些历史遗留版本。从几个大的事件我们可以看出很多问题。首先,TLS的安全更新是所有软件平台必须关注的主要问题。AWS最近几年一直对用户使用的TLS版本提出告警提示。在2022年初有一次提醒用户,TLS-1.2 是TLS版本的最低版本。针对TLS-1.2,redhat 红帽子早在2016年就发布了一个安全漏洞(CVE-2015-7575),此漏洞直接影响了Red Hat Enterprise Linux 6 和 7的发行版本。从具体的功能支持方面,相对于TLS1.3, TLS 1.2 仍然使用多种或强或弱的密码保护机制:

在针对安全单元的使用上和算法方面,TLS 1.3 废弃了多种在TLS1.2 的支持,消除了一些带安全漏洞的加密机制的隐患。具体来说,TLS 1.3 不再使用:

    SSL CompressionStatic key exchange functionsBlock ciphers (CBC)Non-AEAD ciphers (MAC-then-Encrypt)Renegotiation of encryption parameters

同时,TLS 1.3 也取消了对旧版本的,可能有漏洞的SSL ciphers支持,包括:

    RC4DSAMD5SHA1Weak Elliptic CurvesRSA Key ExchangeStatic Diffie-Hellman (DH, ECDH)

目前的TLS 1.3 仅使用以下五个cipher 单元:

    TLS_AES_256_GCM_SHA384TLS_CHACHA20_POLY1305_SHA256TLS_AES_128_GCM_SHA256TLS_AES_128_CCM_8_SHA256TLS_AES_128_CCM_SHA256

如果我们从以下图例中观察的话,TLS 1.2 和TLS 1.3 握手机制对比来看,明显看出,TLS 1.2 的握手机制的流程显然比TLS 1.3 流程多了几个步骤。在服务器端,TLS 1.3 仅进行两次处理,而TLS 1.2 服务器端则需要来回往复进行三次处理。它们之间协商流程的过程有明显差别。在一般情况下,TLS 1.2 (需要300毫秒协商握手)和TLS 1.3(需要200毫秒协商握手) 之间的协商时间相差 100毫秒。

除了本身的一些基础架构的优势以外,在具体的测试过程中,TLS 1.3 的性能表现优于TLS 1.2。 研究人员针对不同的TLS支持包的测试中,在libreSSL连接GnuTLS时,双方创建连接方式,经过测试,TLS 1.3 测试的结果明显优于TLS 1.2 的结果,其结果如下:

在以上对比测试中,TLS1.3 在使用LibreSSL对接GnuTls的测试中,TLS 1.3 平均比TLS1.2 快9.62% 并且其连接的持久性TLS 1.3比TLS 1.2 高19.14%。同样的测试在Openssl连接GnuTLS时也进行了测试实验。以下是测试结果:

其整体平均表现来看,TLS1.3比TLS 1.2 快 8.11%,在连接的持久性方面的表现,TLS 1.3 比TLS 1.2高25.46%。这里,我们的讨论仅仅限于TLS 版本本身和支持包的性能测试方面的讨论,关于TLS 1.3 在其他方面的性能测试,例如不同内核版本的测试,笔者在最后章节中会进一步做详细介绍,这里不再展开讨论。在前面的讨论中,我们分享了关于TLS 1.2 的问题,和TLS 1.3 相比,其握手机制的不足,还有TLS 1.3 性能测试的结果。通过这些数据我们看出,TLS 1.3的部署是迫在眉睫了。为了进一步完善读者的知识点,笔者在接下来的章节中正式讨论关于TLS 1.3和其RFC8446的细节内容。

关于TLS-1.3 的概论

这里,我们重点关注关于TLS-1.3的主要细节部分的内容,例如,背景知识介绍,握手协议概论,表示语言规范化说明等八个主要章节,其他附录部分的语法定义读者可以参考RFC8446详解来进一步确认学习。

关于TLS-1.3规范的背景介绍

TLS的基本功能是提供通信端之间通道的安全,仅确保基础传输的可靠性,完成按序传输的数据流。具体来说,安全通道提供以下安全属性支持:

身份认证:服务器端的通道总是需要认证的,客户端则不一定需要身份认证,客户端的认证是可选认证。身份认证可通过非对称的加密方式,例如RSA,或者Elliptic Curve Digital Signature Algorithm(ECDSA),asymmetricEdwards-Curve Digital Signature Algorithm(EdDSA)或者对称的共享密钥pre-shared key (PSK)来实现。

保密性:通信通道的连接创建以后,终端数据通过通道发送,只有通信端之间可见。TLS不能隐藏数据的长度,通过TLS的数据,可以填补TLS记录管理其长度,使其更加复杂,提高对数据的保护防范来防范分析工具的破解。

完整性:通信端之间创建了连接以后,通信端之间发送数据没有检测机制,也不能被攻击者修改。

有时可能攻击者控制了网络,但是以上属性应该总是要确保的。TLS由两个基本的组件构成:

    握手协议:在下面的章节中将介绍握手协议。握手协议是负责认证通信端身份,协商加密模式,加密模式参数,创建共享的密钥资料信息。握手协议的设计目的是抵抗攻击者的干预,篡改数据等非法操作;如果攻击者进入到了已创建的通道,攻击者不能按照攻击者的目的来强制修改协商模式或者协商参数。记录协议:记录协议是使用已创建的握手协议的参数来保护通信端之间的数据流量。记录协议将数据流量分割为一系列的记录数据,每个记录数据使用流量密钥而且各自独立。

特别说明,TLS是应用层独立协议。对于高级层级的其他协议来说,它是透明的。对于TLS标准来说,它仍然不会对其他协议指定如何配合TLS工作或者安全设置。如何初始化TLS,如何解析安全证书取决于TLS部署上一层应用设计者自己的判断。TLS-1.3不会直接兼容旧版本的TLS,所有TLS版本的工作机制取决于通信端支持的版本,客户端和服务器端之间的TSL协商取决于双方对不同版本的支持。这里,读者必须注意,前面已经间接说明,TLS-1.3也不会向前兼容。因为如果兼容旧版本的TLS的话,可能再次出现旧版本造成的安全漏洞。

TLS-1.3 替代,废弃了旧版本的TLS,包括TLS-1.2(RFC5246),也废弃了TLS ticket 机制(RFC5077),使用新的机制替代。TLS-1.3修改了获得密钥的方法,TLS-1.3也修改了Online Certificate Status Protocol (OCSP)在线证书状态协议,更新为支持RFC6066,废弃了RFC6961。TLS-1.3版本和TLS-1.2版本不同之处在于:

    支持对称加密的机制列表被裁减,裁减的对称加密机制被看作是传统加密机制。保留的都是认证加密关联了AEAD算法的加密机制。cipher suite密件套件概念已经被修改分离,从记录保护机制中分离为认证和密钥交换机制(包括了密钥长度),hash用在密钥导出功能和握手消息认证code中(mac中)。添加了0-RTT模式,在连接创建时对某些应用数据节省了RTT,节省了安全属性维护的成本。动态RSA和Diffie-Hellman cipher suites被移除。现在,所有基于公钥的密钥交换机制提供前向安全性。在ServerHello后,所有握手消息都被加密。所有新引入的EncryptedExtensions消息允许扩展,此扩展以前在ServerHello以明文发送到数据也接受安全保护。密钥导出函数重新设计。因为优化的密钥属性分离,方便分享密码机制。HMAC-based Extract-and-Expand 密钥导出功能作为潜在基础设计。握手状态机经过大幅重新构建,保持一致性,移除了不必要的消息,例如,移除ChangeCipherSpec。Elliptic curve 算法作为基础功能,包括了新的签名算法,例如EdDSA。TLS-1.3移除了point 格式协商。优化了其他加密方式,包括修改RSA padding,使用RSA Probabilistic Signature Scheme (RSASSA-PSS),移除了压缩算法,数字签名算法(DSA)和自定义的Ephemeral Diffie-Hellman (DHE)组。废弃了TLS-1.2的协商机制扩展支持。携带和不携带服务器端状态的会话重启以及基于早期TLS版本的PSK-based 加密套件单元(cipher suites)使用一个新的单个PSK交互机制替代。参考规范更新为RFC5280,不再是RFC3280。

对于TLS-1.2版本来说,更新到TLS-1.3 有部分的影响,主要体现在:

    版本降级保护机制的处理。规范了RSASSA-PSS signature schemes定义”supported_versions” ClientHello 的扩展可以用来协商TLS使用的版本,在偏好中设置支持的ClientHello的历史版本。”signature_algorithms_cert”扩展允许客户端指示它使用的哪个签名算法验证X.509 证书。

TLS 1.3-2-协议概览说明

我们知道,安全通道使用的各种密码参数由TLS握手协议生成。这个TLS的子协议在client和server第一次通信时开始使用。握手协议允许双方协商协议使用的版本、选择密码算法、选择性互相认证,并得到共享的密钥数据。一旦握手协商流程成功,双方开始使用计算出的密钥保护机制来保护应用层数据流量。

其他TLS 1.3相关的性能和技术挑战讨论

通过以上非常大的篇幅,笔者从基础背景知识,关于TLS 1.3的性能优势和规范概览清楚说明了TLS 1.3的技术内容。但是,虽然TLS 1.3性能和安全性方面有了比较大的提升。我们仍然需要从其他方面对其进行讨论,包括了可能面对的潜在风险等,帮助读者能够全面了解TLS 1.3的整体技术状态。下面,笔者就目前关于TLS 1.3 的一些研究成果和大家做进一步分享。内核是操作系统的核心,它扮演着最主要的角色。很多的应用工具都需要在不同内核进行测试才能得到一个非常准确的测试数据,这个测试数据往往能够体现其性能表现。TLS的表现也是如此。

Alexander Krizhanovsky 针对不同的版本的内核,根据TLS 1.2 和TLS 1.3 不同版本的测试。在内核5.7环境中,TLS 1.2 的表现相对TLS 1.3 还是有一点差距的,握手延迟比TLS 1.3要高。

因为很多用户是通过互联网来进行沟通交互的,实际交互过程中,消息中包括了很多的metadata,metadata很可能在不同的保护机制中出现安全泄露。因此,这些metadata的安全也是TLS 安全机制需要保护的。Bryan Ford提出了很多对网络HTTP 2.0 的关于TLS和metadata的建议(Metadata Protection Considerations for TLS Present and Future),读者可参考学习。

总结

在关于TLS 1.3 和历史版本的回顾讨论中,笔者首先讨论了关于TLS的历史版本,TLS 1.2 存在的一些问题,以及最新TLS 1.3 和 TLS 1.2 对比的一些差异,并且进一步介绍了TLS 1.3 的性能方面的优势,算法的先进性等。笔者另外重点对RFC8446做了比较深入的解释说明,帮助读者能够比较完整地了解TLS 1.3的核心内容。最后,从不同角度为读者分享了关于TLS 1.3 的其他的研究成果,希望通过这些讨论能够丰富TLS 1.3的应用学习。

关于更细节的安全算法的测试,SecOps团队运维,测试工具和其他的网页服务器的支持等笔者问进一步讨论,希望读者通过此篇文章的讨论进一步扩展读者自己的知识点。如果读者能够获得更多知识,笔者文章的目的也就达到了。

参考资料:

https://www.rfc-editor.org/rfc/rfc8446

https://www.rfc-editor.org/rfc/rfc5246

www.asterisk.org.cn

www.freepbx.org.cn

www.dinstar.cn

https://github.com/sweis/crypto-might-not-suck

https://access.redhat.com/articles/2112261

www.sip.org.cn

https://www.ndss-symposium.org/wp-content/uploads/2020/02/24203.pdf

https://www.hhs.gov/sites/default/files/securing-ssl-tls-in-healthcare-tlpwhite.pdf

www.gigamon.com

https://aws.amazon.com/tw/blogs/security/tls-1-2-required-for-aws-endpoints/

https://www.a10networks.com/

Alexander Krizhanovsky, Ivan Koveshnikov,Performance study of kernel TLS handshakes

本文来自网络,不代表今日新闻立场,转载请注明出处:https://www.newstoday.cc/l2DBp0D.html
上一篇
下一篇

为您推荐

返回顶部