背景知识
▧▧ 理解https前需要了解的前置知识 ：【加密技术】、【数字签名】、【数字证书】
文中提到的pity源于分享的文章：https://juejin.cn/post/6977935496164933645?searchId=2024042612053378EA2971BD2BB959DD6F
加密技术
-
对称加密： 指的是加密和解密，都是使用同一个密钥，优点是速度快、效率高。缺点是接收方和发送方任一方密钥被泄露都会让加密信息不安全，不适合在互联网上传输密钥，密钥维护的工作量大
-
非对称加密：指的是密钥对的形式，分为公钥和私钥。使用公钥加密的信息只能用私钥解密，反过来使用私钥加密的信息也只能用公钥解密。优点是公钥与私钥无法互推，适合在互联网上传输公钥。用户密钥维护量少，每个用户只需要一个非对称密钥对。缺点是加密效率低
-
两种加密方式配合使用： 使用对称密钥加密信息内容，然后用私钥加密对称密钥，用户拿到信息内容后用公钥解密对称密钥，再用对称密钥解密消息内容。通过两种加密方式的套用，抵消了各自的缺点
-
加密安全：
- 加密方式无关安全强度，决定安全强度的是密钥的长度
- 解密成本也是安全强度的一种，当解密成本大于解密后的收益，也是安全性强的体现
- 密码有效期小于最快的破解时间也是密码强度的体现
数字签名
相当于指纹，一种用于确保数字信息完整性、认证身份和防止否认的技术手段。如：根据散列函数对消息体生成一个256位的摘要A（如HS256），然后使用私钥对该摘要进行加密生成数字签名。用户收到消息后用公钥解密得到摘要A，然后根据同样散列函数对消息体生成一个摘要B，通过对比两个摘要，确认消息体是否被篡改。
.▧▧ 引用下pity里的一个函数，这里使用JWT提供了一种轻量级的方式来实现数字签名的功能，用于确保token的完整性和真实性，本质和数字签名的思想类似，但是JWT用的是对称密钥。
- 在创建token时，将数据和密钥输入到散列函数（如HS256）中，生成一个固定长度的哈希值（签名）
- 在解析token时，按 . 分割，提取出头部、载荷和签名部分，将头部和载荷数据进行 Base64 解码，得到原始的 JSON 数据，使用相同的密钥和算法对原始的 JSON 数据进行签名，得到一个新的签名值，将新计算得到的签名值与从 JWT 中提取的签名部分进行比对，如果两者相同，则表示 JWT 是有效的；否则，表示 JWT 已被篡改或无效
- 另外ExpiredSignatureError只返回时间过期的报错，还有无效token的情况没有分类出来，需要加上 ”except InvalidTokenError“
数字签名这里虽然可以防止消息是否被篡改，但是有个关键点，就是无法保证公钥是否被替换过或者公钥是否属于当前请求的服务器
数字证书
-
数字证书是什么
-
数字证书简称为证书，它由证书授权中心（CA）颁发并进行数字签名，以确保其真实性和可信度。证书包含了拥有者的公钥以及与其相关的身份信息，如姓名、电子邮件地址、组织、有效期等。
-
以testerhome的数字证书为例，在证书上能看到【版本】【序列号】【签名算法】【颁发者】【有效期】【主体】【签名】 等信息，testerhome看得出还是比较穷的，申请的是知名免费的Let's Encrypt证书颁发机构颁发的免费SSL证书，免费的证书有效期是90天，这里可以看到5月10号就要过期了。
-
- 为什么需要数字证书
▧▧ 类似身份证是由公安机关签发的一样，主要作用是用于验证网络通信中的身份和信息的真实性。数字证书最核心的作用就是第三方权威机构证明这个公钥持有者是属于谁的
- 数字证书的应用
- 在TLS握手过程中，客户端使用本地的信任证书列表验证服务器的证书是否有效，以testerhome为例大致过程如下
-
- chrome从testerhome的SSL证书中提取出服务器的数字签名
-
- chrome使用本地信任证书列表（通常是操作系统或浏览器预装的）中的根证书，这些证书包含了可信任的证书颁发机构的公钥。像testerhome的就使用根证书的公钥对testerhome数字证书进行解密，得到哈希值A
-
- chrome使用与testerhome服务器证书中相同的哈希算法（teserhome是SHA-256）对服务器中的公钥、有效期、颁发者等信息进行哈希计算，得到一个哈希值B
-
- 如果A和B两个值相同，则证明服务器证书的数字签名是有效的，未被篡改，里面的公钥也确定是testerhome的
-
http的缺陷
▧▧ http是明文传输协议，数据传输过程中是以纯文本的形式进行传输。这里的明文指的是未经过加密的数据，这些未经过加密的 http 报文（请求行、请求头、主体）在网络上传输的过程，使得其内容容易被窃听者截取和读取。
- 举例pity登录接口，用http进行请求，对网卡进行抓包能得到传输的数据
SSL和TLS
▧▧ 背景： SSL最初由网景公司(Netscape)开发，用于保护网络通信中的隐私、身份验证和数据完整性。SSL的安全性存在一些漏洞和弱点，经过多次迭代增强安全性，在 1999 年更新为 TLS。由于SSL 的最终版本（3.0）与 TLS 的第一版本之间并无明显差异，且这两个术语经常互换使用并混为一谈，现在仍然有人使用 SSL 来指代 TLS，或者使用术语“SSL/TLS ”，所以 SSL 证书（技术上也称为“TLS 证书”）。
- 从上图知道，SSL层夹在应用层和传输层中间，主要分为两层
-
SSL记录协议（SSL Record Protocol ）： 负责将高层协议（如HTTP）的数据进行分割、压缩 解压缩、加密解密、认证，然后交给传输层协议（如TCP）进行传输，确保数据的安全性和完整性（MAC校验）。
-
SSL握手协议（SSL Handshake Protocol）：SSL握手协议位于SSL协议栈的上层，负责在通信双方建立安全的通信连接之前进行身份验证、协商加密算法和生成会话密钥等操作。
- SSL密码参数修改协议（SSL Change Cipher Spec Protocol）：SSL密码参数修改协议是SSL协议栈中的一个子协议，用于通知对方从握手阶段的初始加密状态切换到加密通信状态。它主要包括一个特殊的消息类型 ChangeCipherSpec，该消息指示在此消息之后的所有数据都将使用新的加密参数（如会话密钥）进行加密和解密
- SSL告警协议（SSL Alert Protocol）：SSL告警协议用于在SSL连接中传递警告和错误信息
-
信息安全
▧▧ 信息安全的基本要素：保密性、完整性、可用性、可控性、不可否认性。很明显http协议不具有信息安全的要素特征，因此使用http + ssl 来保证http协议传输的安全性，http是第一个使用SSL保证安全性的应用层协议
https实现
给pity加下证书，
用postman发起登录请求，用wireshark抓包
在进行 HTTPS 请求时，客户端会在 SSL/TLS 握手过程中获取服务器的公钥和数字证书。SSL/TSL 是一种用于保护通信安全的协议，它在建立安全连接时使用了公钥加密技术。TLS 握手包括以下步骤：
- 客户端发送 ClientHello 消息：客户端向服务器发送一个包含支持的 TLS 版本、加密算法和其他相关信息的 ClientHello 消息。
- 服务器发送 ServerHello 消息：服务器从客户端的支持列表中选择一个 TLS 版本、加密算法等，并将其作为 ServerHello 消息的一部分发送回客户端。
- 服务器发送数字证书：服务器会将其数字证书发送给客户端。数字证书中包含了服务器的公钥以及其他身份验证信息，比如服务器的域名等。
-
验证数字证书：客户端会验证服务器发送的数字证书，确保其合法性。这个过程包括检查数字证书的签发者、有效期、域名等信息，并验证证书链的完整性。
-
生成对称密钥：客户端会生成一个对称密钥，并使用服务器的公钥加密后发送给服务器，以便服务器之后能够使用私钥解密。
-
握手完成：TLS 握手完成后，客户端和服务器就可以使用对称密钥进行加密通信了。
为什么代理工具能抓到包
-
原理：基于代理服务器和中间人攻击
-
以Fiddler为例，Fiddler 在计算机上安装了自己的根证书（Fiddler Root Certificate），然后将这个根证书当做受信任的证书。当用户通过 Fiddler 代理访问 HTTPS 网站时，Fiddler 将使用自己的根证书替代原始网站的 SSL 证书，建立一个与用户计算机之间的加密通道。大致流程如下：
-
- 本地系统信任了fiddler生成的自签名证书，配置了fiddler的代理。接着在chrome上发起https请求
-
- fiddler代理收到TLS握手请求，根据请求的地址生成临时证书，该证书用Fiddler的根证书(也就是你信任的那张)进行签名,再发送给chrome
-
- chrome检验证书通过后，与服务器（即代理服务器fiddler）协商出对称密钥 会话密钥A
-
- TLS握手完成后，chrome使用会话密钥A加密应用层数据发给fiddler
-
- fiddler使用会话密钥A解密数据，并以客户端身份与服务器建立了TLS连接并协商出了会话密钥B，把解密出的数据用会话密钥B加密后发给服务器
-
- 服务器收到fiddler的加密数据后用会话密钥B解密得到请求数据，根据请求的数据返回响应，响应使用会话密钥B加密
-
- fiddler收到响应后用会话密钥B解密在用会话密钥A加密转发给chrome
-
-
大致的流程图