1.HTTPS是什么 HTTPS是一个应用层协议,是在HTTP协议的基础上引入了一个加密层的安全通信协议，核心是通过SSL/TLS 协议对传输数据进行加密，确保网络通信的保密性、完整性和身份真实性
HTTP协议内容都是按照文本的方式明文传输的,这就导致在传输过程中出现一些被篡改的情况
原因:我们通过网络传输的所有数据包都会经由运营商的路由器、交换机等网络设备。这意味着运营商可以解析并篡改我们传输的数据内容。
当用户点击"下载按钮"时，实际上是在向服务器发送HTTP请求。正常情况下，服务器返回的HTTP响应会包含该APP的下载链接。但运营商一旦检测到这是"天天动听"的下载请求，就会自动将响应内容篡改为"QQ浏览器"的下载地址。
为什么运营商会进行流量劫持？归根结底是为了牟取利益。💴💴💴
HTTP明文传输本身就存在安全隐患，不仅运营商可以轻易劫持，黑客也同样能从中作梗。想象一下，如果您的个人隐私、支付密码等敏感信息被截获，后果将多么严重。正是出于这样的安全考虑，我们才需要HTTPS加密协议来保障用户信息安全。
2.加密是什么
明文:要传输的原始数据密文:对明文进行加密后使他人不能理解加密:就是把明文(要传输的信息)进行一系列变换,生成密文解密:就是把密文再进行一系列变换,还原成明文密钥:在这个加密解密的过程中,往往需要一个或多个中间的数据,辅助进行这个过程,这样的数据称为密钥 加密解密到如今已经发展成一个独立的学科：密码学
而密码学的奠基人，也正是计算机科学的祖师爷之一，艾伦·麦席森·图灵
3.HTTPS的加密过程 为确保数据安全，需采用"加密"技术。在网络传输过程中，不再直接传送明文，而是传输经过加密处理的"密文"。加密方式主要分为两大类：对称加密和非对称加密。
3.1对称加密 对称加密（Symmetric Encryption）是一种加密和解密使用同一密钥的加密技术，也称为 “单密钥加密”。其核心特点是加密与解密过程共享一个密钥，操作高效且广泛应用于各类场景。
通过同一个"密钥",把明文加密成密文,并且也能把密文揭密成明文
核心原理:
加密过程：明文 + 密钥 → 通过加密算法 → 密文解密过程：密文 + 同一密钥 → 通过解密算法 → 明文核心要求：加密和解密必须使用完全相同的密钥，否则无法还原明文。 举例一个简单的对称加密,按位异或
假设明文a = 1234,密钥key = 8888;加密a^key得到的密文b就是9834
对密文9834再次进行计算b^key,得到的就是原来的明文1234
如果直接把密钥进行明文传输,那么黑客也就能获取密钥啦,那么我们所进行的加密操作就形同虚设了,因此密钥的传输也必须加密传输,要想对密钥进行对称加密,就仍然需要先协商确定一个"密钥的密钥",可是对称加密又是明文传输,此时就陷入了死循环,
“要加密密钥 → 需新密钥 → 新密钥又要加密 → 需更上层密钥……”
此时我们就需要引入非对称加密
3.2非对称加密 非对称加密（Asymmetric Encryption）是一种加密和解密使用不同密钥的加密技术，也称为 “公钥加密”。其核心创新在于通过一对 “公钥” 和 “私钥” 实现加密与解密，解决了对称加密中密钥传输的安全难题。
公钥不怕泄露，私钥不能泄露
核心原理
密钥对：由 “公钥”（Public Key）和 “私钥”（Private Key）组成，两者通过数学算法关联（如大数分解、离散对数），但从公钥无法推导出私钥。加密解密过程：明文 + 公钥 → 通过加密算法 → 密文（只有对应的私钥能解密）。
密文 + 私钥 → 通过解密算法 → 明文（只有对应的公钥能加密）。
明文 + 私钥 → 通过加密算法 → 密文（只有对应的公钥能解密）。
密文 + 公钥 → 通过解密算法 → 明文（只有对应的私钥能解密）。
公钥加密→私钥解密：保证 “消息只有对方能看懂”（保密通信）；
私钥加密→公钥解密：保证 “消息确实是对方发的”（身份验证）。核心特性：公钥可公开传播，私钥必须严格保密；用公钥加密的数据只能用私钥解密，反之亦然（部分算法支持 “私钥加密、公钥解密”，用于签名）。 举例:
A需要向B传递一些重要文件，但B可能不在场。
为此，双方约定如下：
B告诉A："我桌上有个盒子，我会给你一把锁"A将文件放入盒子并用这把锁锁好B随后用对应的钥匙开锁取件 在这个类比中：
锁相当于公钥（可以公开分发）钥匙相当于私钥（必须由B独自保管） 只有持有私钥的人才能解密获取文件内容。
非对称加密加密传输对称密钥
客户端在本地生成对称密钥,通过公钥进行加密,发送给服务器由于中间的网络设备没有私钥,即使截获了数据,也无法还原出内部的原文,也就无法获取到对称密钥服务器通过私钥解密,还原出客户端发送的对称密钥,并且使用这个对称密钥给客户端返回响应数据后续客户端和服务器的通信都只用对称加密即可,由于该密钥只有客户端和服务器两个主机知道,其他主机/设备不知道密钥即使截获数据也没有意义 4.引入证书 4.1"中间人"攻击
客户端如何获取到公钥?客户端如何确定这个公钥不是黑客伪造的? 客户端向服务器请求公钥时,黑客通过入侵网络设备,截获服务器发送的公钥,并将自己生成的公钥发送给客户端
黑客通过替换公钥，让客户端和服务器误以为在安全交换密钥，实际对称密钥被黑客截获。由于非对称加密的 “公钥公开” 特性，客户端无法验证公钥是否真实（这是单纯非对称加密的漏洞）
4.2 引入证书机制 问题的关键就是能够让客户端识别出,拿到的公钥是不是正确的,合理的而不是伪造的公钥
为确保通信安全，服务端在启用HTTPS前需向CA机构申请数字证书。该证书包含申请者信息和公钥等关键数据。当服务器将证书传输至浏览器时，浏览器可直接从中提取公钥。数字证书的作用类似于身份证，用于验证服务端公钥的真实性和权威性。
当你想搭建服务器时,使用HTTPS就需要在公证机构这里申请证书,申请时就需要提交一些资料,如,网站的域名,营业执照,备案号等
申请成功后,公证机构就生成一个"电子证书",证书内容包含
证书发布机构证书有效期公钥证书所有者签名:保证证书合法性的关键要点...
注:申请证书的时候,需要在特定平台生成,会同时生成一对密钥对,即公钥和私钥.这对密钥对就是用来在网络通信中进行明文加密及数字签名的
其中公钥会随着CSR文件一起发给CA进行权威认证,服务端自己保留私钥,用来后续进行通信(主要用来交换对称密钥)
4.3 理解数据签名 数据签名（通常称为 “数字签名”，Digital Signature）是一种基于密码学的安全技术，用于验证数据的完整性（数据未被篡改）和来源真实性（确认数据发送者身份），同时防止发送者事后抵赖。其核心逻辑基于非对称加密和哈希算法
当服务器申请CA证书的时候,CA机构会对该服务器端进行审核,并专门为该网站形成数字签名,过程如下
CA机构拥有非对称加密的私钥pri和公钥pubCA机构对服务端申请的证书明文数据进行hash,形成数据摘要然后对数据摘要用CA私钥pri加密,得到数字签名S 服务端申请的证书明文和数字签名S共同组成了数字证书，这样一份数字证书就可以颁发给服务端了
如何让验证证书是正确的?
客户端拿到服务端的CA证书之后，会将数据和数据签名分开。将数据进行哈希散列形成一个哈希值。再将数据签名使用CA机构的公钥进行解密，也得到一个哈希值。将这两个哈希值进行比较，如果相同，则说明证书是正确的。
服务器申请到证书之后,后续客户端从服务器拿公钥就不只是拿公钥而是拿整个证书,此时客户端就可以凭借证书中的数字签名对证书的合法性进行验证
客户端如何验证数字签名?客户端把证书中的各个字段再算一遍校验和,得到checksum1客户端使用公证机构的公钥,对数字签名进行解密,得到checksum2对比checksum1 == checksum2 如果相等则视为当前证书的各个字段就是和服务器这边发出来的证书是一模一样的,此时就可以认为这是合法证书
如果不相等则意味着证书上的内容被中间的黑客篡改过了,此时浏览器往往就会弹出警告页面,提示用户该网站不安全当前客户端所拿的公证机构的公钥,客户端是如何确定这个公钥是正确的而不是黑客伪造的?
操作系统（如 Windows、Linux、macOS）和浏览器（如 Chrome、Firefox）在开发时，会将一些知名且权威的 CA 机构的根证书预先内置到系统或应用程序中。这些根证书包含了 CA 机构的公钥信息。 当客户端收到一个证书时，它会从根证书开始，按照证书链的顺序进行验证。例如，Windows 系统的证书存储区中就包含了众多受信任的 CA 根证书，浏览器在验证证书时会参考这些内置的根证书信息。黑客可不可以篡改数据后同时更新数字签名,让数字签名解密出来的checksum2和篡改过的checksum1一致呢?
黑客篡改数据后，若想重新生成数字签名，必须使用公证机构的私钥进行加密——而这个私钥是黑客无法获取的。
如果黑客试图使用自生成的私钥呢？客户端使用公证机构的公钥将无法解密。
此时，解密失败会被系统识别为证书异常，从而触发明显的安全警告弹窗。4.4 非对称加密 + 对称加密 + 证书认证 在客户端和服务器刚一建立连接的时候,服务器给客户端返回一个证书,这个证书包含了刚才的公钥,也包含了网站的身份信息
当客户端获取到这个证书之后,会对证书进行校验(防止证书是伪造的)
判定证书的有效期是否过期判断证书的发布机构是否受信任(操作系统已内置的受信任的证书发布机构)验证证书是否被篡改:从系统中拿到该证书发布机构的公钥,对签名进行解密,得到一个hash值(称为数据摘要),设为hash1,然后计算整个证书的hash值,设为hash2,对比hash1和hash2是否相等,如果相等,则说明证书没有被篡改过 客户端与服务器通信的具体流程
客户端生成对称密钥
客户端随机生成一个临时的对称密钥（如 AES 密钥），用于后续加密实际要传输的数据（如网页内容、用户信息等）。这个密钥只在本次会话中使用，称为 “会话密钥”。
客户端获取服务器公钥
服务器提前生成一对非对称密钥（公钥 + 私钥），并将公钥公开（通常通过数字证书发布）。客户端向服务器请求通信时，会获取到服务器的公钥。
客户端用服务器公钥加密对称密钥
客户端用服务器的公钥对自己生成的对称密钥进行加密，然后将加密后的对称密钥发送给服务器。
由于公钥加密的数据只有对应的私钥能解密，即使黑客拦截了加密后的对称密钥，没有服务器的私钥也无法破解。 服务器用私钥解密获取对称密钥
服务器收到加密后的对称密钥后，用自己的私钥解密，得到客户端生成的对称密钥。此时，客户端和服务器都持有了同一把对称密钥，且整个过程中对称密钥未被明文传输。
用对称密钥加密实际通信数据
后续客户端与服务器的所有通信（如请求数据、返回内容），都使用这把对称密钥进行加密和解密。由于对称加密速度快，能高效处理大量数据，同时密钥是安全的，保证了通信的安全性。
5.常见问题5.1 Fiddler等抓包工具，为啥能解析HTTPS的数据? 要解密数据必须获取对称密钥，而Fiddler就是通过中间人攻击来实现这一点的。当我们开启HTTPS选项时，系统会弹出对话框询问是否信任Fiddler提供的证书，一旦选择信任就允许了中间人攻击拿到了对称密钥
伪造自签名证书
攻击者生成一个自签名的根证书（相当于自己当 CA），并诱导用户安装到客户端（如浏览器、操作系统）,当客户端访问真实服务器时，攻击者返回伪造的服务器证书（用自己的私钥签名）拦截握手阶段
预主密钥(密码核心原材料,在证书里) + 客户端和服务器的随机数(加"调味剂"防重复) 按照TLS协议的算法计算出会话密钥,会话密钥会用来加密后续所有的实际数据（比如你浏览网页的内容、登录的密码等）解密通信数据
攻击者拿到会话密钥后，可解密客户端与服务器之间的所有数据（如 HTTPS 请求、用户密码、聊天内容）5.2 中间人有没有可能篡改该证书?
中间人篡改了证书的明文由于他没有CA机构的私钥,所以无法hash之后用私钥加密形成签名,那也就没办法对篡改后的证书形成匹配的签名如果强行篡改,客户端收到该证书后会发现明文和签名解密后的值不一致,则说明证书已被篡改,证书不可信,从而终止向服务器传输信息,防止信息泄露给中间人5.3 中间人整个掉包证书呢？
因为中间人没有 CA 私钥，因此无法生成与CA签名相同的加密哈希值。所以无法制作假的证书。所以中间人只能向 CA 申请真证书，然后用自己申请的证书进行掉包。这个确实能做到证书的整体掉包，但是别忘记，证书明文中包含了域名等服务端 认证信息，如果整体掉包，客户端依旧能够识别出来。永远记住：中间人没有 CA 私钥，所以对任何证书都无法进行合法修改，包括自己的。5.4 为什么摘要内容在网络传输的时候一定要加密形成签名? 常见的摘要算法有:MD5和SHA系列
以MD5为例，我们不需要研究具体的计算签名的过程，只需要了解MD5的特点：
定长：无论多长的字符串，计算出来的MD5值都是固定长度（16字节版本或者32字节版本)分散：源字符串只要改变一点点，最终得到的MD5值都会差别很大。不可逆：通过源字符串生成MD5很容易，但是通过MD5还原成原串理论上是不可能的. 正因为MD5有这样的特性，我们可以认为如果两个字符串的MD5值相同，则认为这两个字符串相同。
理解判定证书篡改的过程：（这个过程就好比判定这个身份证是不是伪造的身份证)
假设我们的证书只是一个简单的字符串hello，对这个字符串计算hash值(比如md5)，结果为
BC4B2A76B9719D91
如果hello中有任意的字符被篡改了，比如变成了hella,那么计算的md5值就会变化很大.
BDBD6F9CF51F2FD8
然后我们可以把这个字符串hello和哈希值BC4B2A76B9719D91从服务器返回给客户端，此时客户端如何验证hello是否是被篡改过?
那么就只要计算hello的哈希值，看看是不是BC4B2A76B9719D91即可.
但是还有个问题，如果黑客把hello篡改了，同时也把哈希值重新计算下，客户端就分辨不出来了呀.
所以被传输的哈希值不能传输明文，需要传输密文。
所以，对证书明文(这里就是“hello”)hash形成散列摘要，然后CA使用自己的私钥加密形成签名，将hello和加密的签名合起来形成CA证书，颁发给服务端，当客户端请求的时候，就发送给客户端，中间人截获了，因为没有CA私钥，就无法更改或者整体掉包，就能安全的证明，证书的合法性。
最后，客户端通过操作系统里已经存的了的证书发布机构的公钥进行解密，还原出原始的哈希值，再进行校验.
5.5 为什么签名不直接加密，而是要先 hash 形成摘要? 这是因为，可能有的签名是很长的，直接加密会造成不必要的损失。而先 hash 可以缩小签名密文的长度,加快数字签名的验证签名的运算速度。