TLS/SSL简介：从加密通信到双向信任
大家平时上网，浏览器地址栏那个小锁图标，背后就是 TLS/SSL 在干活。说白了一句话：TLS/SSL 就是给网络通信加了一把「只有收发双方能打开的锁」。但这把锁到底怎么锁、锁的是谁、谁能开，值得好好聊聊。
我刚开始搞后端集成时，觉得 HTTPS 就是配个证书完事。直到有一次对接一个金融接口，对方要求「双向认证」——说白了就是不光客户端要验服务端，服务端也要验客户端。那才意识到，以前理解的「安全通信」其实漏了一半。
TLS/SSL 是什么？发展简史
SSL（Secure Sockets Layer）最早由网景公司在 90 年代推出，版本 1.0 从未公开，2.0 和 3.0 都先后爆出严重漏洞。后来 IETF 接手并改名 TLS（Transport Layer Security），从 TLS 1.0 一路演进到现在的 TLS 1.3。
你想想看，一个协议活了快三十年，核心目标一直没变：保密性、完整性、身份认证。但具体怎么实现，每代版本都有大改进。
| 版本 | 推出年份 | 主要变化 | 现状 |
|---|---|---|---|
| SSL 2.0 | 1995 | 第一个公开版本，但缺陷很多 | 禁止使用 |
| SSL 3.0 | 1996 | 修复大量漏洞，成为 TLS 前身 | 已弃用（POODLE 攻击） |
| TLS 1.0 | 1999 | 标准化版本，与 SSL 3.0 不兼容 | 逐渐淘汰 |
| TLS 1.1 | 2006 | 加强 CBC 攻击防护 | 少数场景遗留 |
| TLS 1.2 | 2008 | 引入 AEAD、SHA-256、ECC 支持 | 当前主流 |
| TLS 1.3 | 2018 | 握手从 2-RTT 降到 1-RTT，移除不安全算法 | 推荐使用 |
我跟你的建议是：新项目尽量用 TLS 1.3，兼容性考虑至少用 1.2。我见过有的老系统还在跑 TLS 1.0，安全检查一上来直接标红。
单向认证：我们一直在用的「半拉子」安全
最常见的 HTTPS 场景就是单向认证：
客户端连上服务器，服务器出示自己的证书，客户端验证证书的合法性，然后双方协商对称密钥，之后所有通信都加密。
这个过程里，客户端能确认服务器的身份，但服务器对客户端一无所知。换句话说，任何能连上网的人都可以访问这个服务，只要服务器没做额外鉴权。
双向认证：让服务器也「看清」客户端
双向认证（Mutual TLS，mTLS）就是在标准 TLS 握手流程里，增加一步：服务器请求客户端证书，客户端发送自己的证书，服务器验证客户端证书的合法性。只有两边都验过了，握手才算完成。
这样做的好处很明显：
服务端不仅能保证信道加密，还能精确识别每一个客户端是谁。你想想看，在微服务间通信、开放 API 接口、设备接入这些场景里，这台服务器到底是「我的服务」还是「被攻击的靶子」，全看能不能管住接入方。
核心概念：证书、CA、握手流程
证书是个好东西。它就像数字身份证，由权威机构（CA，Certificate Authority）签发。证书里包含了公钥、持有者信息、有效期、CA 签名等。TLS 依赖这套信任链来完成身份验证。
单向认证和双向认证的差别，用一张图就能看明白：
图中左侧是大家熟悉的单向流程，右侧是多出来的客户端证书交互。其实多出来的只有两个消息：服务端发一个 CertificateRequest，客户端回一个 Certificate + CertificateVerify。但就这一步，安全模型完全不一样了。
-verify 或 -Verify 参数就能要求客户端证书。我常用下面这两行来快速验证：# 服务端
openssl s_server -cert server.crt -key server.key -CAfile ca.crt -Verify 1 -port 4433
# 客户端
openssl s_client -connect localhost:4433 -cert client.crt -key client.key -CAfile ca.crt为什么需要双向认证？三个真实场景
单向认证已经够「安全」了，为什么还要麻烦地搞双向？我总结了三个最典型的场景：
- 微服务间 RPC 通信：服务 A 调用服务 B，B 必须确认 A 是内部合法服务，而不是外部恶意请求。用 mTLS 可以在网络层直接做身份认证，省去额外 校验。
- 开放 API 平台：银行、支付这类接口，不仅要保护用户数据，还要验明调用方的身份。客户端证书作为比 更难伪造的凭证，是业界标准做法。
- IoT 设备接入：每个设备有唯一证书，服务器可以通过证书链确认设备是否来自合法制造商。我参与的一个智慧水务项目，用了 mTLS 后设备仿冒攻击直接降到零。