HTTPS原理 - 技术栈

文章目录

[1. 引入对称加密](#1. 引入对称加密)
[2. 传输对称密钥给服务器](#2. 传输对称密钥给服务器)
[3. 引入非对称加密](#3. 引入非对称加密)
[4. 中间人攻击](#4. 中间人攻击)
[5. 避免中间人攻击, 引入证书机制](#5. 避免中间人攻击, 引入证书机制)
- [5.1 证书是什么](#5.1 证书是什么)
- [5.2 客户端验证证书](#5.2 客户端验证证书)
- [5.3 但客户端如何确定这个公证机构的公钥是正确的, 不是黑客伪造的?](#5.3 但客户端如何确定这个公证机构的公钥是正确的, 不是黑客伪造的?)
- [5.4 那我们用fiddler抓包, 是自己植入了根证书吗?](#5.4 那我们用fiddler抓包, 是自己植入了根证书吗?)
[6. HTTPS 服务端与客户端的完整例子](#6. HTTPS 服务端与客户端的完整例子)

HTTP 是明文传输
HTTPS 只是在 HTTP 的基础上引入加密机制
那 HTTPS 是如何加密的?

1. 引入对称加密

客户端和服务器交互过程中, 一个服务器, 对应着多个客户端

因此, 就需要每个客户端连上服务器的时候, 自己生成一个随机的对称密钥, 服务器也得拿到这个密钥, 才能解密

2. 传输对称密钥给服务器

按照这样的传输形式, 密钥明文传输给服务器, 此时黑客就可能接获到这个密钥, 后续的加密形同虚设

3. 引入非对称加密

通过非对称加密, 对要传输的对称密钥进行加密

4. 中间人攻击

黑客的设备, 在客户端面前, 假扮服务器

在服务器面前, 假扮客户端

演技足够好, 骗过双方

5. 避免中间人攻击, 引入证书机制

5.1 证书是什么

一个数字证书实际上是一个标准格式的文件

如果你想要搭建服务器, 使用HTTPS, 就需要在公证机构申请证书

申请的时候, 需要提交一些材料

复制代码

数字证书内容：
├── 版本号
├── 序列号 (唯一ID)
├── 签名算法 (如SHA256-RSA)
├── 颁发者 (CA名称)
├── 有效期 (起止日期)
├── 主体信息 (网站信息)
│   ├── 国家 (C=CN)
│   ├── 组织 (O=Example Inc.)
│   ├── 通用名称 (CN=example.com) ← 关键！
├── 主体公钥信息
│   ├── 算法 (如RSA 2048)
│   └── 公钥数据
├── 扩展信息
│   ├── 备用名称 (SAN, 支持多域名)
│   ├── 密钥用途
│   └── 增强型密钥用途
└── 颁发者签名 ← 最重要的部分！
    ├── 签名算法
    └── 数字签名值

根据这些材料, 公证机构能生成出一个电子证书

签名就是证书中的各个字段综合在一起, 计算校验和

然后把校验和加密得到签名部分

服务器申请到证书之后,

后续客户端从服务器拿公钥, 就不只是拿公钥, 而是拿整个证书

此时, 客户端就可以凭借证书中的数字签名对证书的合法性进行验证

5.2 客户端验证证书

客户端验证数字签名

js 复制代码

// 伪代码表示验证过程
function 验证签名(证书) {
    原始数据 = 证书.除签名外的所有内容;
    收到的签名 = 证书.签名;
    
    // 用CA的公钥解密签名
    解密结果 = RSA_解密(收到的签名, CA公钥);
    
    // 对原始数据计算哈希
    计算哈希 = SHA256(原始数据);
    
    // 比较
    return 解密结果 == 计算哈希;  // 相等则签名有效
}

如果签名能用CA的公钥正确解密，且与证书内容匹配，证明证书确实来自该CA。

5.3 但客户端如何确定这个公证机构的公钥是正确的, 不是黑客伪造的?

这是一个极其关键的问题！这正是数字证书信任体系的核心

因为CA的公钥是预装在您的操作系统和浏览器里的，攻击者无法篡改。

那如果攻击者控制了操作系统，植入了自己的根证书呢？

这是有可能的

5.4 那我们用fiddler抓包, 是自己植入了根证书吗?

是的, Fiddler/Charles等抓包工具能抓HTTPS包，正是因为在您的电脑/手机上植入了它们自己的根证书, 当合法中间人

6. HTTPS 服务端与客户端的完整例子

场景：客户端（浏览器）要安全地发送信用卡号给服务器（电商网站）