SSL/TLS
SSL/TLS是位于TCP/IP 7层协议中的会话层，用于认证用户和服务器，加解密数据以及维护数据的完整性，确保数据在传输过程中不会被修改。
[图片上传失败...(image-d9e6e2-1610506045425)]
TLS（Transport Layer Security，传输层安全协议）是IETF制定的一种新的协议，TLS1.0是建立在SSL3.0协议规范之上，是SSL3.0协议的后续版本，可以理解为SSL3.1。TLS的主要目的是使SSL更加安全，更加完善。TLS记录格式于SSL记录格式相同，但是版本号值不一样，TLS的版本1.0使用的版本号是SSLv3.1。
那么HTTPS究竟是采用对称加密还是非对称加密呢？答案是两者都有。先采用非对称加密传输协商对称加密的密钥，然后用对称加密通信。
HTTPS加密过程
上图是比较粗粒度的讲解了HTTPS的非对称和对称加解密过程：
- 客户端浏览器发起连接。
- WEB服务器将公钥发给客户端。
- 客户端生成一个session key，并且将session key用公钥加密后发送给服务器。
- 服务器用私钥将session key解密出来。
- 客户端和服务器用session key做对称加密通信。
整个流程可以这样抽象，但是实际上session key的生成是需要多次协商的结果，我们暂且这样简单的理解。整个流程会有一个问题，第2步中WEB服务器发给客户端的公钥，万一被中间人修改了呢，换句话说，客户端怎么验证公钥的正确性呢？那就需要讲到数字签名。
数字签名
如上图所示，公钥内容的后面是会跟上一个数字签名，该数字签名是将公钥内容的HASH用私钥加密后的密文。客户端拿到公钥后，会用相同的HASH算法重新算一遍，得到一个HASH值hash1。然后用公钥解密数字签名得到HASH值hash2，如果hash1等于hash2就证明这个公钥是没有被中间人修改的。即使中间人修改了公钥的内容，他也没有私钥可以重新生成数字签名，用户拿到修改后的公钥一算发现HASH不对就会报错。
TLS握手过程
TLS协议版本有多个，下图以1.0.2版本为例。
对于上图可分为4步：
1、客户端发出请求（ClientHello）
首先，客户端先向服务器发出加密通信请求，在这一过程中 客户端需要向服务器提供以下信息：
支持的协议版本 TLS 1.0 2.0
一个客户端生成的随机数，用于一会生成“对话密钥”
支持的加密方法。例如：RSA公钥加密
支持的压缩方法
这里需要知道客户端发送的信息中不包括服务器域名
2.服务器回应(ServerHello)
服务器收到客户端请求后，向客户端发出回应，服务器的回应内容如下
确定使用的加密通信协议版本 TLS1.0 如果与之前的版本不一致，服务器关闭加密通信
一个服务器生成的随机数，用于一会的“对话密钥”
确定使用的加密方法，例如：RSA公钥加密
服务器证书
除此之外，服务器还会需要确定客户端的身份，就会包含一份请求(要求客户端提供客户端证书)
3、客户端回应
客户端收到服务器的证书后，会先去检测收到的服务器证书，是不是可信任的证书。如果证书过期，或者是不可信任的机构颁布，就会向访问者显示一个警告，告诉其是否需要继续通信
如果证书没有问题，客户端就是从证书总提取服务器的公钥，之后想服务器回应以下消息：
一个随机数，该随机数用于服务器公钥加密
编码改变通知
客户端结束握手通知，并且会发送一个Hash值，用来验证之前发送的信息正确性
至此，一共出现了三个随机数：1-3步骤中都会生成随机数(pre-master key)，有个这三个随机数后，客户端和服务器都会同时有三个随机数，接着双方就用商定的加密方法，各自生成本次会话所用的同一把“会话密钥”
4.服务器的回应
服务器收到客户端的第三个随机数后，计算出本次会话所用的会话密钥。之后想客户端发出以下信息：
编码改变通知，表示双方的信息都是用商定后的加密方法发送
服务器握手结束通知，表示服务器的握手截断结束，同样会发送一段HASH给客户端用来校验。
