加密通信原理：对称加密与非对称加密，TLS/SSL握手过程，HTTPS与HTTP的区别
说到加密通信，我第一个想到的是几年前排查一个接口日志异常的场景。当时发现所有请求的body都是明文，敏感数据直接裸奔。原因很简单——开发同学觉得“内网不用加密”。嗯，后来我们补上了TLS，日志里才终于看不到用户密码了。
这一章，我们就来聊聊加密通信的核心。你搞接口日志审计，不理解这些基础，后面根本没法判断“这条日志是不是被人篡改过”。
对称加密：快，但钥匙怎么给？
对称加密，说白了就是加密和解密用同一把钥匙。你拿钥匙锁门，用同一把钥匙开门。常见算法有AES、DES、3DES。现在主流是AES-256，密钥长度256位，暴力破解基本不可能。
关键特点：速度快，适合大量数据加密。但密钥分发是个大难题——你把钥匙给对端的过程中，可能已经被截获了。
我在项目中遇到过一种情况：两个服务之间用预设的AES密钥加密通信。密钥写死在配置文件里，版本管理还提交到了Git。结果可想而知——密钥泄露，日志里全是加密后的乱码，但别人拿着密钥就能解密。我建议：对称密钥一定要定期轮换，且不能硬编码。
| 特性 | 对称加密 | 非对称加密 |
|---|---|---|
| 密钥数量 | 1个（加密/解密共用） | 2个（公钥+私钥） |
| 计算速度 | 快（硬件加速友好） | 慢（数学运算复杂） |
| 典型算法 | AES, ChaCha20 | RSA, ECDSA, Ed25519 |
| 密钥分发 | 困难（需安全通道） | 公钥随便发，私钥自己留 |
| 适用场景 | 大量数据传输 | 密钥交换、数字签名 |
审计小技巧：查看日志中的加密算法标识（比如 cipher suite），能快速判断对方是不是用了弱加密。我见过有人还在用DES，直接标记为高风险。
非对称加密：公钥私钥，两把锁
非对称加密就聪明多了。一公一私两把钥匙。公钥公开，谁都能拿；私钥自己藏着，打死不给别人。用公钥加密的数据，只有私钥能解。反过来，用私钥签名的数据，公钥能验证是谁签的。
我个人习惯叫它“钥匙和锁”的关系。公钥是锁，私钥是钥匙。你给全世界发锁，大家拿锁把数据锁好寄给你，只有你有钥匙能打开。
常见的算法有RSA（2048位以上）和ECC（椭圆曲线）。ECC在同样安全强度下，密钥更短、计算更快。我最近迁移的几个项目都改用Ed25519了，日志签名验证性能提升明显。
避坑指南：我曾经遇到过一个系统，用RSA-1024做令牌签名。1024位在2015年后就被认为不够安全了。检查日志中的证书和密钥长度，低于2048位的直接打“高危”。
TLS/SSL握手过程：一次加密对话的开始
你每次打开HTTPS页面，背后都有一场“握手”。这个过程决定了后续通信用什么密钥、怎么加密。我追踪过无数次加密接口的日志，每次都要先看握手阶段有没有异常——比如证书过期、选择了弱加密套件。
握手的核心流程，我习惯分成四步：
- 客户端问候（ClientHello）：客户端告诉服务器，我支持哪些TLS版本、加密套件。日志里能看到这些信息，比如“TLS 1.2, AES-256-GCM”。
- 服务器问候（ServerHello）：服务器选一套双方都支持的参数，发回自己的数字证书（包含公钥）。
- 密钥交换：客户端验证证书（检查CA链、域名、有效期），然后用服务器的公钥加密一个“预主密钥”发过去。双方用这个预主密钥生成会话密钥。
- 握手完成：双方都用会话密钥加密一条“Finished”消息，对方能解密就说明协商成功。
// 示意：抓包中看到的TLS握手日志（简化）
[Client] ClientHello: TLS 1.3, Ciphers: TLS_AES_256_GCM_SHA384
[Server] ServerHello: TLS 1.3, Cipher: TLS_AES_256_GCM_SHA384
[Server] Certificate: *.example.com, Issuer: DigiCert
[Client] ClientKeyExchange: (encrypted pre-master secret)
[Client] ChangeCipherSpec
[Server] ChangeCipherSpec
[Client] Finished (encrypted)
[Server] Finished (encrypted)
审计重点：TLS版本低于1.2的直接报风险。1.0和1.1已经被弃用了。另外，如果日志里出现“握手失败”或“证书警告”，一定要追查——可能是中间人攻击。
HTTPS与HTTP的区别：不止多一个“S”
HTTP是明文传输，数据在网络上裸奔。你的请求、响应、cookie、表单数据，路上经过的每个节点都能看得一清二楚。你想想看，在公共Wi-Fi上发个登录请求，密码就是送人头的。
HTTPS就是HTTP over TLS。在HTTP外面套了一层TLS加密。数据在传输过程中是密文，只有客户端和服务器能看懂。日志里看到“http://”和“https://”的区别，本质上就是“裸奔”和“穿防弹衣”的区别。
- 端口不同：HTTP默认80，HTTPS默认443。日志里看端口也能判断。
- 证书开销：HTTPS需要CA签发的证书（现在有免费的Let's Encrypt）。
- 性能差异：HTTPS有握手开销，但现代TLS 1.3只需要一次往返，影响很小。
- 安全性：HTTP无法防篡改、防窃听。HTTPS提供加密、完整性校验和身份认证。
我做日志审计时，第一件事就是统计：接口中还有多少是HTTP的？只要发现内网服务之间用HTTP传输敏感数据，立刻标记。很多人觉得内网安全，其实内网攻击面更大——内部人员搞破坏、被入侵后的横向移动，都是通过HTTP明文接口。
检测清单：在日志中搜索“http://”开头的URL。对每个非HTTPS的API接口，确认它是否处理敏感数据。如果是，就算低优先级也要记录在案。
一张图看懂：对称加密 + 非对称加密 + TLS握手
下面这张图把三者关系画清楚了。对称加密负责实际传输、非对称加密负责安全交换对称密钥、TLS握手把它们串起来。你审计加密接口时看到的日志，大部分信息都能在这张图里找到对应位置。
你看完这张图，应该能理解我为什么总说“审计加密接口先看握手日志”。握手阶段的任何异常，比如证书过期、选择了弱加密套件、TLS版本低，都会直接影响后续所有数据的安全性。我曾经修过一个问题：某服务因为客户端库太老，自动协商到了TLS 1.0，日志里全是RC4加密。嗯，那天的安全报告很难看。