快速了解TLS

最新推荐文章于 2024-09-05 16:37:49 发布

大张哥儿

最新推荐文章于 2024-09-05 16:37:49 发布

阅读量34

点赞数

分类专栏：流媒体文章标签：网络服务器网络协议后端音视频

本文链接：https://blog.csdn.net/zrush/article/details/134673466

版权

流媒体专栏收录该内容

7 篇文章 0 订阅

订阅专栏

简介

传输层安全性协议（英语：Transport Layer Security，缩写作TLS），及其前身安全套接层（Secure Sockets Layer，缩写作SSL）是一种安全协议，目的是为互联网通信提供安全及数据完整性保障。网景公司（Netscape）在1994年推出首版网页浏览器，网景导航者时，推出HTTPS协议，以SSL进行加密，这是SSL的起源。IETF将SSL进行标准化，1999年公布第一版TLS标准文件。随后又公布RFC 5246 （2008年8月）与RFC 6176（2011年3月）。在浏览器、邮箱、即时通信、VoIP、网络传真等应用程序中，广泛支持这个协议。主要的网站，如Google、Facebook等也以这个协议来创建安全连线，发送数据。目前已成为互联网上保密通信的工业标准。
SSL包含记录层（Record Layer）和传输层，记录层协议确定传输层数据的封装格式。传输层安全协议使用X.509认证，之后利用非对称加密演算来对通信方做身份认证，之后交换对称密钥作为会谈密钥（Session key）。这个会谈密钥是用来将通信两方交换的数据做加密，保证两个应用间通信的保密性和可靠性，使客户与服务器应用之间的通信不被攻击者窃听。

TLS版本记录

协议	年份
SSL 1.0	未知
SSL 2.0	1995
SSL 3.0	1996
TLS 1.0	1999
TLS 1.1	2006
TLS 1.2	2008
TLS 1.3	2018

安全网络编程
早期的研究工作，为方便改造原有网络应用程序，在1993年已经有了相似的Berkeley套接字安全传输层API方法。

SSL 1.0、2.0和3.0

SSL（Secure Sockets Layer）是网景公司（Netscape）设计的主要用于Web的安全传输协议，这种协议在Web上获得了广泛的应用。
基础算法由作为网景公司的首席科学家塔希尔·盖莫尔（Taher Elgamal）编写，所以他被人称为“SSL之父”。
2014年10月，Google发布在SSL 3.0中发现设计缺陷，建议禁用此一协议。攻击者可以向TLS发送虚假错误提示，然后将安全连接强行降级到过时且不安全的SSL 3.0，然后就可以利用其中的设计漏洞窃取敏感信息。Google在自己公司相关产品中陆续禁止回溯兼容，强制使用TLS协议。Mozilla也在11月25日发布的Firefox34中彻底禁用了SSL 3.0。微软同样发出了安全通告。

1.0版本从未公开过，因为存在严重的安全漏洞。
2.0版本在1995年2月发布，但因为存在数个严重的安全漏洞而被3.0版本替代。
3.0版本在1996年发布，是由网景工程师Paul Kocher、Phil Karlton和Alan Freier完全重新设计的。较新版本的SSL/TLS基于SSL 3.0。SSL 3.0作为历史文献IETF通过RFC 6101发表。

TLS 1.0

IETF将SSL标准化，即RFC 2246，并将其称为TLS（Transport Layer Security）。从技术上讲，TLS 1.0与SSL 3.0的差异非常微小。但正如RFC所述"the differences between this protocol and SSL 3.0 are not dramatic, but they are significant enough to preclude interoperability between TLS 1.0 and SSL 3.0"（本协议和SSL 3.0之间的差异并不是显著，却足以排除TLS 1.0和SSL 3.0之间的互操作性）。TLS 1.0包括可以降级到SSL 3.0的实现，这削弱了连接的安全性。

TLS 1.1

TLS 1.1在RFC 4346中定义，于2006年4月发表，它是TLS 1.0的更新。在此版本中的差异包括：

添加对CBC攻击的保护：
- 隐式IV被替换成一个显式的IV。
- 更改分组密码模式中的填充错误。
支持IANA登记的参数。

TLS 1.2

TLS 1.2在RFC 5246中定义，于2008年8月发表。它基于更早的TLS 1.1规范。主要区别包括：

可使用密码组合选项指定伪随机函数使用SHA-256替换MD5-SHA-1组合。
可使用密码组合选项指定在完成消息的哈希认证中使用SHA-256替换MD5-SHA-1算法，但完成消息中哈希值的长度仍然被截断为96位。
在握手期间MD5-SHA-1组合的数字签名被替换为使用单一Hash方法，默认为SHA-1。
增强服务器和客户端指定Hash和签名算法的能力。
扩大经过身份验证的加密密码，主要用于GCM和CCM模式的AES加密的支持。
添加TLS扩展定义和AES密码组合。所有TLS版本在2011年3月发布的RFC 6176中删除了对SSL的兼容，这样TLS会话将永远无法协商使用的SSL 2.0以避免安全问题。

TLS 1.3

TLS 1.3在RFC 8446 [2]中定义，于2018年8月发表。它基于更早的TLS 1.2规范，与TLS 1.2的主要区别包括：

将密钥协商和认证算法从密码包中分离出来。
移除脆弱和较少使用的命名椭圆曲线支持（参见椭圆曲线密码学）。
移除MD5和SHA-224密码散列函数的支持。
请求数字签名，即便使用之前的配置。
集成HKDF和半短暂DH提议。
替换使用PSK和票据的恢复。
支持1-RTT握手并初步支持0-RTT。
通过在(EC)DH密钥协议期间使用临时密钥来保证完善的前向安全性。
放弃许多不安全或过时特性的支持，包括数据压缩、重新协商、非AEAD密码本、静态RSA和静态DH密钥交换、自定义DHE分组、点格式协商、更改密码本规范的协议、UNIX时间的Hello消息，以及长度字段AD输入到AEAD密码本。
禁止用于向后兼容性的SSL和RC4协商。
集成会话散列的使用。
弃用记录层版本号和冻结数以改进向后兼容性。
将一些安全相关的算法细节从附录移动到标准，并将ClientKeyShare降级到附录。
添加带有Poly1305消息验证码的ChaCha20流加密。
添加Ed25519和Ed448数字签名算法。
添加x25519和x448密钥交换协议。
将支持加密服务器名称指示（EncryptedServerNameIndication, ESNI）。

网络安全服务（NSS）是由Mozilla开发并由其网络浏览器Firefox使用的加密库，自2017年2月起便默认启用TLS 1.3。随后TLS 1.3被添加到2017年3月发布的Firefox 52.0中，但它由于某些用户的兼容性问题，默认情况下禁用。直到Firefox 60.0才正式默认启用。
Google Chrome曾在2017年短时间将TLS 1.3设为默认，然而由于类似Blue Coat Systems等不兼容组件而被取消。
wolfSSL在2017年5月发布的3.11.1版本中启用了TLS 1.3。作为第一款支持TLS 1.3部署，wolfSSL 3.11.1 支持 TLS 1.3 Draft 18（现已支持到Draft 28），同时官方也发布了一系列关于TLS 1.2和TLS 1.3性能差距的博客。

TLS握手过程

客户端发送请求给服务端

客户端发送的内容主要包含如下几个部分：

TLS的版本。
随机数，用于后续双方使用对称加密交流的密钥。
客户端所支持的加密套件（cipher suites）。

加密套件是一个专有名词，包含三个部分：

密钥交换算法：决定客户端与服务器之间在握手时如何身份验证;
批量加密算法：加密消息流，TLS完成之后使用的HTTP消息加密算法(对称加密)；
消息认证码算法：创建消息摘要, 报文的信息摘要算法，也就是信息的校验码用于信息完整性校验。

服务端发送响应给客户端

服务端回复的内容主要包含如下几个部分：

双方交互所使用的TLS的版本。
服务端所生成的一个随机数，用于后续协商结束后使用对称加密交流时的密钥。
从客户端发送过来的加密套件选择一个作为后续通信的基础。

服务端发送证书文件（CA证书链），同时客户端对证书合法性进行校验（验签名等）

服务端会将它的证书链发送给客户端。证书链基于这样一个逻辑事实：首先A（它一定是一个受信任的证书颁发机构）是可信任的，那么A说B是可以信任的那么B就是可以信任的，B再说C是可以信任的那么C也是可信任的。
另外一个事实是，购买CA证书其实就是让CA机构使用CA机构自己的privateKey给你的pubkey的做次加密生成一个签名。
由于在第2步中服务端已将相关的加密算法确认好，所以在这一步中，客户端可以使用相关算法来校验服务端的证书了。

证书的验证大体流程：

读取CA证书文件的公钥签名及证书的颁发机构；
根据颁发机构获取该机构的根证书ROOT CA读取根证书（已信任）的公钥
使用根证书的公钥对签名（这个签名实际上是一次非对称加密的结果，因为它是由证书颁发机构的privateKey加密得到的）解密出CA的实际公钥，和CA文件直接读取的进行匹配
如果匹配则继续读取其他的配置判断是否过期等等

它大概长下面这个样：
在这里插入图片描述

校验完成后再生成第三个随机数，第三个随机数用证书的公钥加密后发送给服务端，服务端用私钥解密得到第三个随机数。
校验完成后客户端继续生成一个随机数并发送给服务端，至此，双方在协商的过程中一共生成三次随机数，而在协商过程中生成的这些随机数会被用来生成一个会话密钥。
服务端和客户端手握三个随机数然后各自生成会话密钥进行会话加密。

随后的通信会使用之前协商好的对称加密算法进行沟通，而密钥就是根据之前的三个随机数生成的。
以后数据的加密解密就会使用会话密钥进行对称加解密了