本篇文章主要记录Https的相关知识内容。主要参考了一些公众号（特别是小林Coding的图解网络）

名词概念

Https的整体流程

客户端通过发送Client Hello报文开始SSL通信。报文中包含客户端支持的SSL的指定版本、加密组件（Cipher Suite）列表（所使用的加密算法及密钥长度等）。
服务器可进行SSL通信时，会以Server Hello报文作为应答。和客户端一样，在报文中包含SSL版本以及加密组件。服务器的加密组件内容是从接收到的客户端加密组件内筛选出来的。
服务器发送Certificate报文。报文中包含公开密钥证书
服务器发送Server Hello Done报文通知客户端，最初阶段的SSL握手协商部分结束
客户端以Client Key Exchange报文作为回应。报文中包含通信加密中使用的一种被称为Pre-master secret的随机密码串。该报文已用步骤3中的公开密钥进行加密。
客户端继续发送Change Cipher Spec报文。该报文会提示服务器，在此报文之后的通信会采用Pre-master secret密钥加密
客户端发送Finished报文。该报文包含连接至今全部报文的整体校验值。这次握手协商是否能够成功，要以服务器是否能够正确解密该报文作为判定标准。
服务器同样发送Change Cipher Spec报文（见步骤6）
服务器同样发送Finished报文。
服务器和客户端的Finished报文交换完毕之后，SSL连接就算建立完成。
疑问点

客户端怎么判断服务器的数字证书是真的还是假的呢？
HTTPS如何解决安全问题
| HTTP风险项 | HTTP具体风险原因解释 | HTTPS解决方式 | | —- | —- | —- | | 窃听风险 | HTTP是明文传输，数据包在网络上传输，谁拿到了都可以看里面的内容 | 对传输内容加密呗 | | 篡改风险 | 可以修改服务端原传输内容，比如植入一些广告 | 还是加密就可以解决，只要秘钥不泄露 | | 冒充风险 | 服务器B冒充服务器A | 对服务器进行身份认证，通过数字证书 |

https的实现是在http和TCP层之间加入了TLS协议，来解决安全问题。TLS过程实际就是通信秘钥交换的过程。不同的秘钥交换算法。TLS握手过程也不同

通过WireShark抓包分析，当然这个包不是我抓的（小林Coding中抓的），但是我可以分析一下

可以清楚的看到：

本次握手除了上面的信息还有个重要信息是数字证书，至于客户端如何校验这个证书，我单独拆一个小节整理一下。

最后客户端会再发一个消息（用生成的会话秘钥加密），把之前数据做个摘要。以验证加密通信是否可⽤和之前握⼿信息是否有被中途篡改过。

交换会话秘钥（客户端秘钥）前，都是明文传输

服务器也是同样的操作，发「Change Cipher Spec」和「Encrypted Handshake Message」消息，如果双⽅都验证加密和解密没问题，那么握⼿正式完成。
后面就是会话密钥通信了

客户端数字证书验证
在前面说到服务端会返回一个数字证书和公钥。那么数据证书是什么？客户端又是怎么去验证的呢？我们下面就一起看一看。

数字证书的内容
公钥：额，原来公钥也放在数字证书里。那么上面都说错了。不过没关系
持有者信息
证书认证机构信息（CA）
CA对这份文件的数字签名使用的算法
证书有效期
额外信息：我也不知道是哪些信息
数字证书的作用
告诉客户端，我服务器端是合法的。至于合法和不合法的判断就需要一个大家都信得过的机构。
这机构就是CA
数字证书的签发和认证

签发证书流程
- CA将持有者公钥、用途、颁发者、有效日期打成一个包，使用hash计算得到一个值
- CA将使用自己的私钥对hash值加密，生成证书签名
- 最后第二步的签名和第一步的一些信息合在一起便是一个数字证书
证书认证流程
- 客户端使用同样的hash算法，获取证书的 H1
- 通过浏览器和OS集成的CA公钥信息，解密其证书签名，得到H2
- H1和H2相同则安全，证书可信
  
  证书链
- 客户端收到baidu.com的证书后，证书的签发者不是根证书，于是无法根据本地根证书的公钥去验证证书
- 于是，根据baidu.com的签发者，找到baidu.com的签发机构A
- 签发机构A的上级机构就是根机构，所以可以用根证书公钥验证这个中间机构A
- 中间签发机构A被信任后,可以利用这个A的公钥验证baidu.com证书