说到HTTPS，就需要知道HTTP。我们知道这两个都是应用层方面的协议，HTTP是无状态的，因为他的报文是明文，很容易被人截取后篡改。也就是说，他是不安全的。
然而在我们主机与目标服务器进行信息交互的过程中，不可避免地会涉及到支付、登录后等进行的一系列需要保密和其他的相关操作信息。于是出现了HTTPS协议
HTTPS 的原理
HTTPS 简介
由于HTTP 协议通信的不安全性，所以人们为了防止信息在传输过程中遭到泄漏或者篡改，就想出来对传输通道进行加密的方式https。https 是一种加密的超文本传输协议，它与HTTP 在协议差异在于对数据传输的过程中，https 对数据做了完全加密。由于http 协议或者https协议都是处于TCP 传输层之上，同时网络协议又是一个分层的结构，所以在tcp 协议层之上增加了一层SSL（Secure Socket Layer，安全层）或者TLS（Transport Layer Security） 安全层传输协议组合使用用于构造加密通道；
HTTPS 的实现原理
初始化过程
首先，服务端需要先申请整数，服务端生成一个公私钥（s.pub/s.pri）同时保存自己的私钥。
紧接着，需要把公钥、国家、城市、域名、签名算法等重要信息发送给CA机构。
CA机构会把服务端传过来的公钥进行加密，数字等进行数据，把客户端的私钥来加密服务端的公钥，生成数字证书。并且内置倒浏览器里面。
请求交互时的过程:
- 客户端发起请求(Client Hello 包)
a) 三次握手，建立TCP 连接
b) 支持的协议版本(TLS/SSL)
c) 客户端生成的随机数client.random，后续用于生成“对话密钥”
d) 客户端支持的加密算法
e) sessionid，用于保持同一个会话（如果客户端与服务器费尽周折建立了一个HTTPS 链接，刚建完就断了，也太可惜）
- 服务端收到请求，然后响应（Server Hello）
a) 确认加密通道协议版本
b) 服务端生成的随机数server.random，后续用于生成“对话密钥”
c) 确认使用的加密算法（用于后续的握手消息进行签名防止篡改）
d) 响应服务器证书（CA 机构颁发给服务端的证书）
- 客户端收到证书进行验证
a) 验证证书是否是上级CA 签发的, 在验证证书的时候，浏览器会调用系统的证书管理器接口对证书路径中的所有证书一级一级的进行验证，只有路径中所有的证书都是受信的，整个验证的结果才是受信。
b) 服务端返回的证书中会包含证书的有效期，可以通过失效日期来验证证书是否过期。
c) 验证证书是否被吊销了
d) 前面我们知道CA 机构在签发证书的时候，都会使用自己的私钥对证书进行签名。
证书里的签名算法字段 sha256RSA 表示CA 机构使用sha256对证书进行摘要，然后使用RSA 算法对摘要进行私钥签名，而我们也知道RSA 算法中，使用私钥签名之后，只有公钥才能进行验签。
e) 浏览器使用内置在操作系统上的CA机构的公钥对服务器的证书进行验签。确定这个证书是不是由正规的机构颁发。验签之后得知CA 机构使用sha256 进行证书摘要，然后客户端再使用sha256 对证书内容进行一次摘要，如果得到的值和服务端返回的证书验签之后的摘要相同，表示证书没有被修改过。
f) 验证通过后，就会显示绿色的安全字样。
g) 客户端生成随机数，验证通过之后，客户端会生成一个随机数pre-master secret ， 客户端根据之前的： Client.random +sever.random + pre-master 生成对称密钥然后使用证书中的公钥进行加密，同时利用前面协商好的加密算法，将握手消息取HASH 值，然后用“随机数加密“握手消息+握手消息HASH 值（签名）”然后传递给服务器端；(在这里之所以要取握手消息的HASH值，主要是把握手消息做一个签名，用于验证握手消息在传输过程中没有被篡改过。)
- 服务端接收随机数
a) 服务端收到客户端的加密数据以后，用自己的私钥对密文进行解密。然后得到client.random/server.random/pre-master secret. ,再用随机数密码 解密 握手消息与HASH 值，并与传过来的HASH 值做对比确认是否一致。
b) 然后用随机密码加密一段握手消息(握手消息+握手消息的HASH 值 )给客户端。
- 客户端接收消息
a) 客户端用随机数解密并计算握手消息的HASH，如果与服务端发来的HASH 一致，此时握手过程结束，
b) 之后所有的通信数据将由之前交互过程中生成的pre master
secret / client.random/server.random 通过算法得出sessionKey，作为后续交互过程中的对称密钥。
整理不易，喜欢帮我点个赞。
