对称加密与非对称加密：聊聊 HTTPS 的“锁”与“钥匙”
搞 HTTPS 改造，逃不开两个核心概念——对称加密和非对称加密。说白了，一个用同一把钥匙开门，一个用两把钥匙分工。
我刚开始接触时也觉得绕，但后来发现，理解它们之间的“相爱相杀”，才能真正懂 HTTPS 握手。
对称加密：快，但钥匙怎么给？
对称加密，加密解密用的是同一把密钥。就像家里的防盗门，你和家人都用同一种钥匙。
优点很明显：快，非常快。你想想看，数据量大时，CPU 资源全耗在加解密上，业务还跑不跑？
常见对称加密算法
- AES（Advanced Encryption Standard）：目前最主流，密钥长度 128/192/256 位。AES-256 是国家级加密标准。
- DES（Data Encryption Standard）：老古董了，56 位密钥。我 2015 年给一个旧系统做改造时，发现它还在用 DES。嗯，直接秒破。千万别再用了。
- 3DES（Triple DES）：DES 的升级版，本质是三次 DES。性能差，现在也不推荐。
我的个人习惯：在 HTTPS 场景下，我只用 AES-256-GCM。它不光加密，还带认证，能防篡改。你想想看，如果加密后数据被中间人改了，光解密有用吗？
但对称加密有个致命问题——密钥怎么安全地给到对方？
如果你把密钥通过网络明文发给对方，中间人截获后，加密就形同虚设。这就是著名的密钥分发问题。
非对称加密：慢，但能解决“钥匙传递”
非对称加密用一对密钥：公钥和私钥。公钥公开，私钥自己藏着。
公钥加密的数据，只能用私钥解密。私钥签名的数据，只能用公钥验证。这就是最核心的“不对称”关系。
我曾经掉进一个坑：某次线上事故，同事把 RSA 私钥的密码设成了“password”。我建议他想想，公钥加密私钥解密，如果私钥泄露，相当于谁都能假扮你。私钥密码必须足够强。
非对称加密算法里，最出名的是 RSA 和 ECC（椭圆曲线加密）。
| 特性 | RSA | ECC |
|---|---|---|
| 安全性基础 | 大整数因数分解 | 椭圆曲线离散对数 |
| 同等安全强度下密钥长度 | 2048 位起 | 256 位即可（对应 RSA-3072） |
| 加解密速度 | 慢 | 相对略快 |
| 证书场景 | 最广泛、兼容性最好 | 越来越流行（Apple、Google 力推） |
你可能会问：ECC 密钥这么短，为什么没完全替代 RSA？
根因是兼容性。我测试过，某些老旧设备只支持 RSA 证书。但如果是新项目，我建议直接上 ECC 或混用。
密钥交换：如何在不安全信道上安全协商？
非对称加密解决了公钥传输问题，但握手时双方怎么协商出一个对称密钥呢？这里就要用到密钥交换协议。
经典的方案是 Diffie-Hellman 密钥交换（DH）。
简单来说，双方各自生成一个私密数字，再通过公开信息，最终计算出同一个共享密钥。中间人即使拦截了所有公开数据，也无法算出这个密钥。
- 传统 DH：参数固定，每次会话一样，不安全。
- DHE（Ephemeral DH）：每次会话临时生成一把“一次性”的 DH 密钥，前向安全性更好。即使私钥泄露，历史会话依然安全。
- ECDHE（Elliptic Curve Diffie-Hellman Ephemeral）：基于椭圆曲线的 DHE，性能更强。HTTPS 里现在主流就是它。
我的建议：在 HTTPS 改造中，请务必拒绝 RSA 密钥交换（它没有前向安全性）。优先启用 ECDHE。
混合加密机制：取长补短
你看，对称加密快但不安全传递密钥，非对称加密安全传递密钥但慢。那怎么办？
答案是混合加密——用非对称加密安全传递对称密钥，再用对称密钥加密真正的数据。
这就是 HTTPS 握手的核心逻辑之一。
混合加密的典型流程（以 TLS 1.2 为例）
- 客户端向服务器打招呼，发送支持的加密套件列表。
- 服务器选择一套，并把自己的证书（含公钥）发给客户端。
- 客户端验证证书有效性。
- 验证 CA 签名
- 检查域名是否匹配
- 检查是否在有效期内
- 检查是否已被吊销
- 客户端生成一个随机对称密钥（即 premaster secret），用服务器的公钥加密后发给服务器。
- 服务器用私钥解密，拿到对称密钥。
- 双方用这个对称密钥开始加密通信（通常用 AES-GCM）。
避坑指南
做了这么多年运维，我在 HTTPS 改密上踩过不少坑。这里列几个最常见的：
- 别用 RSA 密钥交换：我曾经在某个项目中看到，HTTPS 配置里默认用了 TLS_RSA_WITH_AES_128_CBC_SHA。这种套件没有前向安全性。一旦私钥泄露，历史会话全完蛋。赶紧换 ECDHE。
- 密钥长度别选错：RSA 至少 2048 位，ECC 至少 256 位。我用过 1024 位的 RSA 证书，嗯，Nginx 启动都报“weak key”。
- 证书私钥的访问权限：私钥文件建议设为 600，只对 root 可读。我见过有人把私钥上传到 GitHub，还加了 .gitignore……
- 注意加密套件的顺序：优先把高安全性的套件放前面，比如 ECDHE+AES256-GCM+SHA384。低安全性的放后面兜底。
我的一个小技巧：用 OpenSSL 测试你站点的加密套件。命令：openssl s_client -connect yourdomain.com:443 -cipher 'ECDHE+AESGCM'。没报错就说明配置对了。
小结
对称加密快，非对称加密安全。混合加密机制把两者结合起来，是 HTTPS 的基石。
你想想看，如果只用对称加密，密钥泄露问题怎么解？如果只用非对称加密，那每个请求都做公钥运算，服务端不炸才怪。
嗯，我个人的经验是，理解这套机制，后面再看 TLS 版本、证书链、OCSP 那些，就会豁然开朗。