不过，大多数运行HTTPS的web服务器都不需要客户端提供证书，如果服务器需要验证客户端的身份，一般是通过用户名和密码、手机验证码等之类的凭证来完成。对于更高安全级别要求的系统，如大额网银转账等，则会提供双向认证的场景，来确保对客户身份提供认证性。
早期的TLS密钥交换用的是RSA算法，目前主流都是用ECDHE算法来做密钥交换的。下面我们分别来介绍下。
5.4.1、基于TLS1.2的HTTPS连接过程 5.4.1.1、RSA密钥交换算法这个过程稍微有点复杂，还是先上图，流程的关键部分都加上了注释，后面详细解释。
如上图：
首先是TCP三次握手，握手成功之后，就可以开始通过TCP传输数据了；
接下来是TLS握手的流程：
Client Hello：客户端生成一个Client Random随机数，明文发送给服务器，同时提供自己的 TLS版本号，以及自己支持的加密套件；
Server Hello：服务器收到之后，也生成了一个Server Random随机数，明文发送给客户端，同时告知自己选择的TLS版本号，以及选择的加密套件；
Server Certificate：服务器发送自己的证书给到客户端；
Server Hello Done：提示服务器信息发送完毕；
客户端收到证书之后进行证书的校验，确保公钥是合法的；
Client Key Exchange：客户端生成一个PreMaster随机数，通过服务器的公钥加密传输给服务器；
这个时候客户端和服务器都有三个参数：Server Random、Client Random、PreMaster，其中PreMaster是无法被不怀好意的人截获的，通过这三个参数，生成对称密钥；
客户端Change Cipher Spec：客户端通知服务器后续改用刚刚生成的密钥进行加密通信；
客户端Encrypted Handshake Message：客户端准备用刚刚的参数加密传输，验证加密通信；
服务器Change Cipher Spec：服务器也通知客户端后续改用刚刚生成的密钥进行加密通信；
服务器Encrypted Handshake Message：服务器准备用刚刚的参数加密传输，验证加密通信；
在双方都确认好了之后，最后是验证的消息。
这里的核心是：通过非对称加密交换参数，生成对称通信加密的密钥，其中PreMaster是非对称加密传输的，保证了不会泄露通信加密的密钥。
下面我们再来看看主流的ECDHE密钥交换算法的HTTPS连接过程。
5.4.1.2、ECDHE密钥交换算法我把与基于RSA算法的连接过程的差异步骤都进行高亮显示了，如下图：
这里我重点说明不一样的地方：
Server Key Exchange：在服务端发送完证书之后，多了这一步，这个是椭圆曲线参数Server Params，为了保证认证性，这里同时生成了Server Params的签名，一起发给客户端；
Client Key Exchange：这里不再是直接发送客户端生成PreMaster，而是生成客户端的椭圆曲线参数Client Params，直接传送给服务端；接着，客户端和服务端双方通过ECDHE算法用Client Params和Server Params算出最终的PreMaster，这个PreMaster是保证不会被截获的。这样双方就有了：Client Random，Server Random，PreMaster参数了，通过这三个参数就可以生成通信密钥了；
在客户端发送了Encrypted Handshake Message之后，就立刻发送测试包了，不用等到服务端发送完Encrypted Handshake Message。
5.4.2、TLS1.3对安全性和性能的提升TLS1.3是2018年发布的，这个版本中对安全性和性能上有了大幅度提升。
5.4.2.1、安全性提升这个版本中砍掉了很多不够安全点加密套件中的算法，只提供了少而精的加密套件。
密钥交换算法废弃了RSA，更好地保证了安全性，不会因为RSA私钥泄露导致历史报文被破解的问题出现。