HTTPS安全机制：从加密到证书全解析
目录
1.HTTPS是什么
2.加密是什么
3.HTTPS的加密过程
3.1对称加密
3.2非对称加密
4.引入证书
4.1"中间人"攻击
4.2 引入证书机制
4.3 理解数据签名
4.4 非对称加密 + 对称加密 + 证书认证
5.常见问题
5.1 Fiddler等抓包工具，为啥能解析HTTPS的数据?
5.2 中间人有没有可能篡改该证书?
5.3 中间人整个掉包证书呢？
5.4 为什么摘要内容在网络传输的时候一定要加密形成签名?
5.5 为什么签名不直接加密，而是要先 hash 形成摘要?
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和公钥pub
- CA机构对服务端申请的证书明文数据进行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是否相等,如果相等,则说明证书没有被篡改过
5.常见问题
5.1 Fiddler等抓包工具，为啥能解析HTTPS的数据?
要解密数据必须获取对称密钥，而Fiddler就是通过中间人攻击来实现这一点的。当我们开启HTTPS选项时，系统会弹出对话框询问是否信任Fiddler提供的证书，一旦选择信任就允许了中间人攻击拿到了对称密钥
- 生成自签名根证书，经用户安装后获客户端信任，替换服务器证书；
- 拦截握手阶段的预主密钥和随机数，算出会话密钥（对称密钥）；
- 用会话密钥解密通信数据，实现解析。
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 可以缩小签名密文的长度,加快数字签名的验证签名的运算速度。