TLS安全协议介绍
2020-03-10 22:45:06 
阿炯
传输层安全性协议(英语：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、网络传真等应用程序中，广泛支持这个协议，当前已成为互联网上保密通信的工业标准。
SSL包含记录层(Record Layer)和传输层，记录层协议确定传输层数据的封装格式。传输层安全协议使用X.509认证，之后利用非对称加密演算来对通信方做身份认证，之后交换对称密钥作为会谈密钥(Session key)。这个会谈密钥是用来将通信两方交换的数据做加密，保证两个应用间通信的保密性和可靠性，使客户与服务器应用之间的通信不被攻击者窃听。
TLS协议采用主从式架构模型，用于在两个应用程序间透过网络创建起安全的连线，防止在交换数据时受到窃听及篡改。其优势是与高层的应用层协议(如HTTP、FTP、Telnet等)无耦合。应用层协议能透明地运行在TLS协议之上，由TLS协议进行创建加密信道需要的协商和认证。应用层协议传送的数据在通过TLS协议时都会被加密，从而保证通信的私密性。
TLS协议是可选的，必须配置客户端和服务器才能使用。主要有两种方式实现这一目标：一个是使用统一的TLS协议端口(例如：用于HTTPS的端口443)；另一个是客户端请求服务器连接到TLS时使用特定的协议机制(例如：邮件、新闻协议和STARTTLS)。一旦客户端和服务器都同意使用TLS协议，他们通过使用一个握手过程协商出一个有状态的连接以传输数据。通过握手，客户端和服务器协商各种参数用于创建安全连接：
当客户端连接到支持TLS协议的服务器要求创建安全连接并列出了受支持的密码组合(加密密码算法和加密哈希函数)，握手开始。
服务器从该列表中决定加密和散列函数，并通知客户端。
服务器发回其数字证书，此证书通常包含服务器的名称、受信任的证书颁发机构(CA)和服务器的公钥。
客户端确认其颁发的证书的有效性。
为了生成会话密钥用于安全连接，客户端使用服务器的公钥加密随机生成的密钥，并将其发送到服务器，只有服务器才能使用自己的私钥解密。
利用随机数，双方生成用于加密和解密的对称密钥。这就是TLS协议的握手，握手完毕后的连接是安全的，直到连接(被)关闭。如果上述任何一个步骤失败，TLS握手过程就会失败，并且断开所有的连接。
TLS利用密钥算法在互联网上提供端点身份认证与通讯保密，其基础是公钥基础设施。不过在实现的典型例子中，只有网络服务者被可靠身份验证，而其客户端则不一定。这是因为公钥基础设施普遍商业运营，电子签名证书通常需要付费购买。协议的设计在某种程度上能够使主从架构应用程序通讯本身预防窃听、干扰和消息伪造。
TLS包含三个基本阶段：
对等协商支持的密钥算法
基于非对称密钥的信息传输加密和身份认证、基于PKI证书的身份认证
基于对称密钥的数据传输保密
在第一阶段，客户端与服务器协商所用密码算法。当前广泛实现的算法选择如下：
公钥私钥非对称密钥保密系统：RSA、Diffie-Hellman、DSA;
对称密钥保密系统：RC2、RC4、IDEA、DES、Triple DES、AES以及Camellia；
单向散列函数：MD5、SHA1以及SHA256。
运行过程
SSL/TLS协议的基本思路是采用公钥加密法，也就是说，客户端先向服务器端索要公钥，然后用公钥加密信息，服务器收到密文后，用自己的私钥解密。但也有两个问题。
(1)如何保证公钥不被篡改？
解决方法：将公钥放在数字证书中。只要证书是可信的，公钥就是可信的。
(2)公钥加密计算量太大，如何减少耗用的时间？
解决方法：每一次对话(session)，客户端和服务器端都生成一个"对话密钥"(session key)，用它来加密信息。由于"对话密钥"是对称加密，所以运算速度非常快，而服务器公钥只用于加密"对话密钥"本身，这样就减少了加密运算的消耗时间。
因此，SSL/TLS协议的基本过程是这样的：
(1) 客户端向服务器端索要并验证公钥。
(2) 双方协商生成"对话密钥"。
(3) 双方采用"对话密钥"进行加密通信。
上面过程的前两步，又称为"握手阶段"(handshake)。
发展历史
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也在Firefox 34中彻底禁用了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登记的参数。
微软、Google、苹果、Mozilla四家浏览器业者将在2020年终止支持TLS 1.0及1.1版。
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 中定义，于2018年8月发表。它基于更早的TLS 1.2规范，与TLS 1.2的主要区别包括：
将密钥交换算法(如ECDHE)和认证算法(如RSA)从密码包中分离出来。
移除MD5密码散列函数的支持。
请求数字签名，即便使用之前的配置。
集成HKDF和半短暂DH提议。
替换使用PSK和票据的恢复。
支持1-RTT握手并初步支持0-RTT。
通过在密钥协商期间使用临时密钥来保证完善的前向安全性。
放弃许多不安全或过时特性的支持，包括数据压缩、重新协商、非AEAD加密算法、静态RSA和静态DH密钥交换、自定义DHE分组、点格式协商、更改密码本规范的协议、UNIX时间的Hello消息，以及长度字段AD输入到AEAD密码本。
禁止用于向后兼容性的SSL和RC4协商。
集成会话散列的使用。
弃用记录层版本号和冻结数以改进向后兼容性。
将一些安全相关的算法细节从附录移动到标准，并将ClientKeyShare降级到附录。
添加带有Poly1305消息验证码的ChaCha20流加密。
添加Ed25519和Ed448数字签名算法。
添加x25519和x448密钥交换协议。
将支持加密服务器名称指示(Encrypted Server Name Indication, 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等不兼容组件而被取消。
TLS 1.3 是时隔九年对 TLS 1.2 之前版本的新升级，也是迄今为止改动最大的一次。TLSv1.3 与之前的协议有较大差异，主要在于：
1、不再允许出现 DSA 证书，需要使用 ECDSA、RSA 替换；
2、相比过去的的版本，引入了新的密钥协商机制 — PSK 支持 0-RTT 数据传输，在建立连接时节省了往返时间 废弃了 3DES、RC4、AES-CBC 等加密组件，废弃了 SHA1、MD5 等哈希算法，ServerHello 之后的所有握手消息采取了加密操作，可见明文大大减少且不再允许对加密报文进行压缩、不再允许双方发起重协商。
对比旧协议中的不足，TLS 1.3 确实可以称得上是向前迈了一大步。既避免之前版本出现的缺陷，也减少了 TLS 握手的时间。TLS 1.3 与以前的版本相比具有如下两个大的优势，分别是：
1、重新协商
TLSv1.3 不再支持重新协商，所以在调用 SSL_renogotiate() 以及 SSL_renegotiate_abbreviated() 时将会报错。而重新协商最常见的场景是更新链接的密钥，可以通过 SSL_key_update() 进行更新。
2、会话复用
在 TLSv1.2 协议中，会话是在握手阶段完成的，通过该会话可以在后续的握手过程中简化流程，通过 SSL_get1_session() 函数可以获取；而在 TLSv1.3 版本中，会话是在握手成功后创建的，在正常在握手完成后，服务端会主动发送多个与会话相关的详细信息。会话复用有两种方式：
A) Session IDs RFC-5246；
B) Session Tickets RFC-5077 。
当然，更多的参考还是要看官方使用介绍。
IETF 正式弃用 TLS 1.0 和 TLS 1.1
IETF（国际互联网工程任务组）已于2021年3月下旬宣布正式弃用 TLS 1.0 和 TLS 1.1。公告写道，TLS 1.0 (RFC 2246) 和 TLS 1.1 (RFC 4346) 已被正式弃用。这些版本缺乏对当前和推荐的加密算法以及机制的支持，许多政府和行业对使用 TLS 的应用现在都要求避免使用这些旧 TLS 版本。
TLS 1.2 在2008年成为 IETF 推荐的版本（2018年被 TLS 1.3 淘汰），因此 IETF 认为已预留足够的时间来让使用者摆脱对旧版本 TLS 的依赖。它还表示，移除对旧版本的支持可以减少攻击面，减少错误配置的机会，并简化库和产品的维护。TLS 1.0 于1999年发布，在其发布近20年的时候——大概是2018年，IETF 就已开始讨论弃用 TLS 1.0 和 1.1。当时几家主流的浏览器也纷纷宣布将于2020年弃用 TLS 1.0 和 TLS 1.1 的计划。SSL Labs 最新的数据显示：
99.3% 网站支持 TLS 1.2 （或更高版本）
42.9% 网站支持 TLS 1.3
0.7% 网站只支持 TLS 1.0
TLS 1.3 于2018年8月发表，它的突破性改进包括握手更快从而加快连接速度、简化支持的加密方式、速度和性能优于 TLS 1.2。
相关算法
密钥交换和密钥协商
在客户端和服务器开始交换TLS所保护的加密信息之前，他们必须安全地交换或协定加密密钥和加密数据时要使用的密码。用于密钥交换的方法包括：使用RSA算法生成公钥和私钥(在TLS 握手协议中被称为TLS_RSA)、Diffie-Hellman(在TLS握手协议中被称为TLS_DH)、临时Diffie-Hellman(在TLS握手协议中被称为TLS_DHE)、椭圆曲线迪菲-赫尔曼(在TLS握手协议中被称为TLS_ECDH)、临时椭圆曲线Diffie-Hellman(在TLS握手协议中被称为TLS_ECDHE)、匿名Diffie-Hellman(在TLS握手协议中被称为TLS_DH_anon)和预共享密钥(在TLS握手协议中被称为TLS_PSK)。
TLS_DH_anon和TLS_ECDH_anon的密钥协商协议不能验证服务器或用户，因为易受中间人攻击因此很少使用。只有TLS_DHE和TLS_ECDHE提供前向保密能力。
在交换过程中使用的公钥/私钥加密密钥的长度和在交换协议过程中使用的公钥证书也各不相同，因而提供的强健性的安全。2013年7月，Google宣布向其用户提供的TLS加密将不再使用1024位公钥并切换到至少2048位，以提高安全性。
数据完整性
消息认证码(MAC)用于对数据完整性进行认证。HMAC用于CBC模式的块密码和流密码，AEAD用于身份验证加密，例如GCM模式和CCM模式。
认证的过程
双向证书认证的SSL握手过程，以下简要介绍SSL协议的工作方式。客户端要收发几个握手信号：
发送一个“ClientHello”消息，内容包括：支持的协议版本，比如TLS1.0版，一个客户端生成的随机数(稍后用于生成“会话密钥”)，支持的加密算法(如RSA公钥加密)和支持的压缩算法。
然后收到一个“ServerHello”消息，内容包括：确认使用的加密通信协议版本，比如TLS 1.0版本(如果浏览器与服务器支持的版本不一致，服务器关闭加密通信)，一个服务器生成的随机数(稍后用于生成“对话密钥”)，确认使用的加密方法(如RSA公钥加密)，服务器证书。
当双方知道了连接参数，客户端与服务器交换证书(依靠被选择的公钥系统)。这些证书通常基于X.509，不过已有草案支持以OpenPGP为基础的证书。服务器请求客户端公钥。客户端有证书即双向身份认证，没证书时随机生成公钥。
客户端与服务器通过公钥保密协商共同的主私钥(双方随机协商)，这通过精心谨慎设计的伪随机数功能实现。结果可能使用Diffie-Hellman交换，或简化的公钥加密，双方各自用私钥解密。所有其他关键数据的加密均使用这个“主密钥”。数据传输中记录层(Record layer)用于封装更高层的HTTP等协议。记录层数据可以被随意压缩、加密，与消息验证码压缩在一起。每个记录层包都有一个Content-Type段用以记录更上层用的协议。
握手阶段的详细过程
"握手阶段"涉及四次通信，我们一个个来看。需要注意的是，"握手阶段"的所有通信都是明文的。
1、客户端发出请求(ClientHello)
首先，客户端(通常是浏览器)先向服务器发出加密通信的请求，这被叫做ClientHello请求。在这一步，客户端主要向服务器提供以下信息。
(1) 支持的协议版本，比如TLS 1.0版。
(2) 一个客户端生成的随机数，稍后用于生成"对话密钥"。
(3) 支持的加密方法，比如RSA公钥加密。
(4) 支持的压缩方法。
这里需要注意的是，客户端发送的信息之中不包括服务器的域名。也就是说，理论上服务器只能包含一个网站，否则会分不清应该向客户端提供哪一个网站的数字证书。这就是为什么通常一台服务器只能有一张数字证书的原因。对于虚拟主机的用户来说，这当然很不方便。2006年，TLS协议加入了一个Server Name Indication扩展，允许客户端向服务器提供它所请求的域名。
2 、服务器回应(SeverHello)
服务器收到客户端请求后，向客户端发出回应，这叫做SeverHello。服务器的回应包含以下内容。
(1) 确认使用的加密通信协议版本，比如TLS 1.0版本。如果浏览器与服务器支持的版本不一致，服务器关闭加密通信。
(2) 一个服务器生成的随机数，稍后用于生成"对话密钥"。
(3) 确认使用的加密方法，比如RSA公钥加密。
(4) 服务器证书。
除了上面这些信息，如果服务器需要确认客户端的身份，就会再包含一项请求，要求客户端提供"客户端证书"。比如，金融机构往往只允许认证客户连入自己的网络，就会向正式客户提供USB密钥，里面就包含了一张客户端证书。
3、客户端回应
客户端收到服务器回应以后，首先验证服务器证书。如果证书不是可信机构颁布、或者证书中的域名与实际域名不一致、或者证书已经过期，就会向访问者显示一个警告，由其选择是否还要继续通信。
如果证书没有问题，客户端就会从证书中取出服务器的公钥。然后，向服务器发送下面三项信息。
(1) 一个随机数。该随机数用服务器公钥加密，防止被窃听。
(2) 编码改变通知，表示随后的信息都将用双方商定的加密方法和密钥发送。
(3) 客户端握手结束通知，表示客户端的握手阶段已经结束。这一项同时也是前面发送的所有内容的hash值，用来供服务器校验。
上面第一项的随机数，是整个握手阶段出现的第三个随机数，又称"pre-master key"。有了它以后，客户端和服务器就同时有了三个随机数，接着双方就用事先商定的加密方法，各自生成本次会话所用的同一把"会话密钥"。
至于为什么一定要用三个随机数：
"不管是客户端还是服务器，都需要随机数，这样生成的密钥才不会每次都一样。由于SSL协议中证书是静态的，因此十分有必要引入一种随机因素来保证协商出来的密钥的随机性。
对于RSA密钥交换算法来说，pre-master-key本身就是一个随机数，再加上hello消息中的随机，三个随机数通过一个密钥导出器最终导出一个对称密钥。
pre master的存在在于SSL协议不信任每个主机都能产生完全随机的随机数，如果随机数不随机，那么pre master secret就有可能被猜出来，那么仅适用pre master secret作为密钥就不合适了，因此必须引入新的随机因素，那么客户端和服务器加上pre master secret三个随机数一同生成的密钥就不容易被猜出了，一个伪随机可能完全不随机，可是是三个伪随机就十分接近随机了，每增加一个自由度，随机性增加的可不是一。"
此外，如果前一步，服务器要求客户端证书，客户端会在这一步发送证书及相关信息。
4、服务器的最后回应
服务器收到客户端的第三个随机数pre-master key之后，计算生成本次会话所用的"会话密钥"。然后，向客户端最后发送下面信息。
(1)编码改变通知，表示随后的信息都将用双方商定的加密方法和密钥发送。
(2)服务器握手结束通知，表示服务器的握手阶段已经结束。这一项同时也是前面发送的所有内容的hash值，用来供客户端校验。
至此，整个握手阶段全部结束。接下来客户端与服务器进入加密通信，就完全是使用普通的HTTP协议，只不过用"会话密钥"加密内容。
参考来源：
传输层安全性协议
TLS协议运行机制的概述
SSL包含记录层(Record Layer)和传输层，记录层协议确定传输层数据的封装格式。传输层安全协议使用X.509认证，之后利用非对称加密演算来对通信方做身份认证，之后交换对称密钥作为会谈密钥(Session key)。这个会谈密钥是用来将通信两方交换的数据做加密，保证两个应用间通信的保密性和可靠性，使客户与服务器应用之间的通信不被攻击者窃听。
TLS协议采用主从式架构模型，用于在两个应用程序间透过网络创建起安全的连线，防止在交换数据时受到窃听及篡改。其优势是与高层的应用层协议(如HTTP、FTP、Telnet等)无耦合。应用层协议能透明地运行在TLS协议之上，由TLS协议进行创建加密信道需要的协商和认证。应用层协议传送的数据在通过TLS协议时都会被加密，从而保证通信的私密性。
TLS协议是可选的，必须配置客户端和服务器才能使用。主要有两种方式实现这一目标：一个是使用统一的TLS协议端口(例如：用于HTTPS的端口443)；另一个是客户端请求服务器连接到TLS时使用特定的协议机制(例如：邮件、新闻协议和STARTTLS)。一旦客户端和服务器都同意使用TLS协议，他们通过使用一个握手过程协商出一个有状态的连接以传输数据。通过握手，客户端和服务器协商各种参数用于创建安全连接：
当客户端连接到支持TLS协议的服务器要求创建安全连接并列出了受支持的密码组合(加密密码算法和加密哈希函数)，握手开始。
服务器从该列表中决定加密和散列函数，并通知客户端。
服务器发回其数字证书，此证书通常包含服务器的名称、受信任的证书颁发机构(CA)和服务器的公钥。
客户端确认其颁发的证书的有效性。
为了生成会话密钥用于安全连接，客户端使用服务器的公钥加密随机生成的密钥，并将其发送到服务器，只有服务器才能使用自己的私钥解密。
利用随机数，双方生成用于加密和解密的对称密钥。这就是TLS协议的握手，握手完毕后的连接是安全的，直到连接(被)关闭。如果上述任何一个步骤失败，TLS握手过程就会失败，并且断开所有的连接。
TLS利用密钥算法在互联网上提供端点身份认证与通讯保密，其基础是公钥基础设施。不过在实现的典型例子中，只有网络服务者被可靠身份验证，而其客户端则不一定。这是因为公钥基础设施普遍商业运营，电子签名证书通常需要付费购买。协议的设计在某种程度上能够使主从架构应用程序通讯本身预防窃听、干扰和消息伪造。
TLS包含三个基本阶段：
对等协商支持的密钥算法
基于非对称密钥的信息传输加密和身份认证、基于PKI证书的身份认证
基于对称密钥的数据传输保密
在第一阶段，客户端与服务器协商所用密码算法。当前广泛实现的算法选择如下：
公钥私钥非对称密钥保密系统：RSA、Diffie-Hellman、DSA;
对称密钥保密系统：RC2、RC4、IDEA、DES、Triple DES、AES以及Camellia；
单向散列函数：MD5、SHA1以及SHA256。
运行过程
SSL/TLS协议的基本思路是采用公钥加密法，也就是说，客户端先向服务器端索要公钥，然后用公钥加密信息，服务器收到密文后，用自己的私钥解密。但也有两个问题。
(1)如何保证公钥不被篡改？
解决方法：将公钥放在数字证书中。只要证书是可信的，公钥就是可信的。
(2)公钥加密计算量太大，如何减少耗用的时间？
解决方法：每一次对话(session)，客户端和服务器端都生成一个"对话密钥"(session key)，用它来加密信息。由于"对话密钥"是对称加密，所以运算速度非常快，而服务器公钥只用于加密"对话密钥"本身，这样就减少了加密运算的消耗时间。
因此，SSL/TLS协议的基本过程是这样的：
(1) 客户端向服务器端索要并验证公钥。
(2) 双方协商生成"对话密钥"。
(3) 双方采用"对话密钥"进行加密通信。
上面过程的前两步，又称为"握手阶段"(handshake)。
发展历史
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也在Firefox 34中彻底禁用了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登记的参数。
微软、Google、苹果、Mozilla四家浏览器业者将在2020年终止支持TLS 1.0及1.1版。
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 中定义，于2018年8月发表。它基于更早的TLS 1.2规范，与TLS 1.2的主要区别包括：
将密钥交换算法(如ECDHE)和认证算法(如RSA)从密码包中分离出来。
移除MD5密码散列函数的支持。
请求数字签名，即便使用之前的配置。
集成HKDF和半短暂DH提议。
替换使用PSK和票据的恢复。
支持1-RTT握手并初步支持0-RTT。
通过在密钥协商期间使用临时密钥来保证完善的前向安全性。
放弃许多不安全或过时特性的支持，包括数据压缩、重新协商、非AEAD加密算法、静态RSA和静态DH密钥交换、自定义DHE分组、点格式协商、更改密码本规范的协议、UNIX时间的Hello消息，以及长度字段AD输入到AEAD密码本。
禁止用于向后兼容性的SSL和RC4协商。
集成会话散列的使用。
弃用记录层版本号和冻结数以改进向后兼容性。
将一些安全相关的算法细节从附录移动到标准，并将ClientKeyShare降级到附录。
添加带有Poly1305消息验证码的ChaCha20流加密。
添加Ed25519和Ed448数字签名算法。
添加x25519和x448密钥交换协议。
将支持加密服务器名称指示(Encrypted Server Name Indication, 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等不兼容组件而被取消。
TLS 1.3 是时隔九年对 TLS 1.2 之前版本的新升级，也是迄今为止改动最大的一次。TLSv1.3 与之前的协议有较大差异，主要在于：
1、不再允许出现 DSA 证书，需要使用 ECDSA、RSA 替换；
2、相比过去的的版本，引入了新的密钥协商机制 — PSK 支持 0-RTT 数据传输，在建立连接时节省了往返时间 废弃了 3DES、RC4、AES-CBC 等加密组件，废弃了 SHA1、MD5 等哈希算法，ServerHello 之后的所有握手消息采取了加密操作，可见明文大大减少且不再允许对加密报文进行压缩、不再允许双方发起重协商。
对比旧协议中的不足，TLS 1.3 确实可以称得上是向前迈了一大步。既避免之前版本出现的缺陷，也减少了 TLS 握手的时间。TLS 1.3 与以前的版本相比具有如下两个大的优势，分别是：
1、重新协商
TLSv1.3 不再支持重新协商，所以在调用 SSL_renogotiate() 以及 SSL_renegotiate_abbreviated() 时将会报错。而重新协商最常见的场景是更新链接的密钥，可以通过 SSL_key_update() 进行更新。
2、会话复用
在 TLSv1.2 协议中，会话是在握手阶段完成的，通过该会话可以在后续的握手过程中简化流程，通过 SSL_get1_session() 函数可以获取；而在 TLSv1.3 版本中，会话是在握手成功后创建的，在正常在握手完成后，服务端会主动发送多个与会话相关的详细信息。会话复用有两种方式：
A) Session IDs RFC-5246；
B) Session Tickets RFC-5077 。
当然，更多的参考还是要看官方使用介绍。
IETF 正式弃用 TLS 1.0 和 TLS 1.1
IETF（国际互联网工程任务组）已于2021年3月下旬宣布正式弃用 TLS 1.0 和 TLS 1.1。公告写道，TLS 1.0 (RFC 2246) 和 TLS 1.1 (RFC 4346) 已被正式弃用。这些版本缺乏对当前和推荐的加密算法以及机制的支持，许多政府和行业对使用 TLS 的应用现在都要求避免使用这些旧 TLS 版本。
TLS 1.2 在2008年成为 IETF 推荐的版本（2018年被 TLS 1.3 淘汰），因此 IETF 认为已预留足够的时间来让使用者摆脱对旧版本 TLS 的依赖。它还表示，移除对旧版本的支持可以减少攻击面，减少错误配置的机会，并简化库和产品的维护。TLS 1.0 于1999年发布，在其发布近20年的时候——大概是2018年，IETF 就已开始讨论弃用 TLS 1.0 和 1.1。当时几家主流的浏览器也纷纷宣布将于2020年弃用 TLS 1.0 和 TLS 1.1 的计划。SSL Labs 最新的数据显示：
99.3% 网站支持 TLS 1.2 （或更高版本）
42.9% 网站支持 TLS 1.3
0.7% 网站只支持 TLS 1.0
TLS 1.3 于2018年8月发表，它的突破性改进包括握手更快从而加快连接速度、简化支持的加密方式、速度和性能优于 TLS 1.2。
相关算法
密钥交换和密钥协商
在客户端和服务器开始交换TLS所保护的加密信息之前，他们必须安全地交换或协定加密密钥和加密数据时要使用的密码。用于密钥交换的方法包括：使用RSA算法生成公钥和私钥(在TLS 握手协议中被称为TLS_RSA)、Diffie-Hellman(在TLS握手协议中被称为TLS_DH)、临时Diffie-Hellman(在TLS握手协议中被称为TLS_DHE)、椭圆曲线迪菲-赫尔曼(在TLS握手协议中被称为TLS_ECDH)、临时椭圆曲线Diffie-Hellman(在TLS握手协议中被称为TLS_ECDHE)、匿名Diffie-Hellman(在TLS握手协议中被称为TLS_DH_anon)和预共享密钥(在TLS握手协议中被称为TLS_PSK)。
TLS_DH_anon和TLS_ECDH_anon的密钥协商协议不能验证服务器或用户，因为易受中间人攻击因此很少使用。只有TLS_DHE和TLS_ECDHE提供前向保密能力。
在交换过程中使用的公钥/私钥加密密钥的长度和在交换协议过程中使用的公钥证书也各不相同，因而提供的强健性的安全。2013年7月，Google宣布向其用户提供的TLS加密将不再使用1024位公钥并切换到至少2048位，以提高安全性。
数据完整性
消息认证码(MAC)用于对数据完整性进行认证。HMAC用于CBC模式的块密码和流密码，AEAD用于身份验证加密，例如GCM模式和CCM模式。
认证的过程
双向证书认证的SSL握手过程，以下简要介绍SSL协议的工作方式。客户端要收发几个握手信号：
发送一个“ClientHello”消息，内容包括：支持的协议版本，比如TLS1.0版，一个客户端生成的随机数(稍后用于生成“会话密钥”)，支持的加密算法(如RSA公钥加密)和支持的压缩算法。
然后收到一个“ServerHello”消息，内容包括：确认使用的加密通信协议版本，比如TLS 1.0版本(如果浏览器与服务器支持的版本不一致，服务器关闭加密通信)，一个服务器生成的随机数(稍后用于生成“对话密钥”)，确认使用的加密方法(如RSA公钥加密)，服务器证书。
当双方知道了连接参数，客户端与服务器交换证书(依靠被选择的公钥系统)。这些证书通常基于X.509，不过已有草案支持以OpenPGP为基础的证书。服务器请求客户端公钥。客户端有证书即双向身份认证，没证书时随机生成公钥。
客户端与服务器通过公钥保密协商共同的主私钥(双方随机协商)，这通过精心谨慎设计的伪随机数功能实现。结果可能使用Diffie-Hellman交换，或简化的公钥加密，双方各自用私钥解密。所有其他关键数据的加密均使用这个“主密钥”。数据传输中记录层(Record layer)用于封装更高层的HTTP等协议。记录层数据可以被随意压缩、加密，与消息验证码压缩在一起。每个记录层包都有一个Content-Type段用以记录更上层用的协议。
握手阶段的详细过程
"握手阶段"涉及四次通信，我们一个个来看。需要注意的是，"握手阶段"的所有通信都是明文的。
1、客户端发出请求(ClientHello)
首先，客户端(通常是浏览器)先向服务器发出加密通信的请求，这被叫做ClientHello请求。在这一步，客户端主要向服务器提供以下信息。
(1) 支持的协议版本，比如TLS 1.0版。
(2) 一个客户端生成的随机数，稍后用于生成"对话密钥"。
(3) 支持的加密方法，比如RSA公钥加密。
(4) 支持的压缩方法。
这里需要注意的是，客户端发送的信息之中不包括服务器的域名。也就是说，理论上服务器只能包含一个网站，否则会分不清应该向客户端提供哪一个网站的数字证书。这就是为什么通常一台服务器只能有一张数字证书的原因。对于虚拟主机的用户来说，这当然很不方便。2006年，TLS协议加入了一个Server Name Indication扩展，允许客户端向服务器提供它所请求的域名。
2 、服务器回应(SeverHello)
服务器收到客户端请求后，向客户端发出回应，这叫做SeverHello。服务器的回应包含以下内容。
(1) 确认使用的加密通信协议版本，比如TLS 1.0版本。如果浏览器与服务器支持的版本不一致，服务器关闭加密通信。
(2) 一个服务器生成的随机数，稍后用于生成"对话密钥"。
(3) 确认使用的加密方法，比如RSA公钥加密。
(4) 服务器证书。
除了上面这些信息，如果服务器需要确认客户端的身份，就会再包含一项请求，要求客户端提供"客户端证书"。比如，金融机构往往只允许认证客户连入自己的网络，就会向正式客户提供USB密钥，里面就包含了一张客户端证书。
3、客户端回应
客户端收到服务器回应以后，首先验证服务器证书。如果证书不是可信机构颁布、或者证书中的域名与实际域名不一致、或者证书已经过期，就会向访问者显示一个警告，由其选择是否还要继续通信。
如果证书没有问题，客户端就会从证书中取出服务器的公钥。然后，向服务器发送下面三项信息。
(1) 一个随机数。该随机数用服务器公钥加密，防止被窃听。
(2) 编码改变通知，表示随后的信息都将用双方商定的加密方法和密钥发送。
(3) 客户端握手结束通知，表示客户端的握手阶段已经结束。这一项同时也是前面发送的所有内容的hash值，用来供服务器校验。
上面第一项的随机数，是整个握手阶段出现的第三个随机数，又称"pre-master key"。有了它以后，客户端和服务器就同时有了三个随机数，接着双方就用事先商定的加密方法，各自生成本次会话所用的同一把"会话密钥"。
至于为什么一定要用三个随机数：
"不管是客户端还是服务器，都需要随机数，这样生成的密钥才不会每次都一样。由于SSL协议中证书是静态的，因此十分有必要引入一种随机因素来保证协商出来的密钥的随机性。
对于RSA密钥交换算法来说，pre-master-key本身就是一个随机数，再加上hello消息中的随机，三个随机数通过一个密钥导出器最终导出一个对称密钥。
pre master的存在在于SSL协议不信任每个主机都能产生完全随机的随机数，如果随机数不随机，那么pre master secret就有可能被猜出来，那么仅适用pre master secret作为密钥就不合适了，因此必须引入新的随机因素，那么客户端和服务器加上pre master secret三个随机数一同生成的密钥就不容易被猜出了，一个伪随机可能完全不随机，可是是三个伪随机就十分接近随机了，每增加一个自由度，随机性增加的可不是一。"
此外，如果前一步，服务器要求客户端证书，客户端会在这一步发送证书及相关信息。
4、服务器的最后回应
服务器收到客户端的第三个随机数pre-master key之后，计算生成本次会话所用的"会话密钥"。然后，向客户端最后发送下面信息。
(1)编码改变通知，表示随后的信息都将用双方商定的加密方法和密钥发送。
(2)服务器握手结束通知，表示服务器的握手阶段已经结束。这一项同时也是前面发送的所有内容的hash值，用来供客户端校验。
至此，整个握手阶段全部结束。接下来客户端与服务器进入加密通信，就完全是使用普通的HTTP协议，只不过用"会话密钥"加密内容。
参考来源：
传输层安全性协议
TLS协议运行机制的概述