4、传输层安全：TLS/SSL协议详解、证书管理、mTLS双向认证

说到分布式系统的安全，传输层安全绝对是绕不开的一环。我个人习惯把TLS/SSL比作系统间的「加密隧道」——数据在进去之前是明文，出来之后还是明文，但在隧道里谁也别想偷看。今天我们就来聊聊这个隧道是怎么挖的，以及怎么把它挖得更牢固。

4.1 TLS/SSL协议：从握手到加密

先说说TLS和SSL的关系。SSL是前辈，TLS是接班人。现在大家说的TLS，其实已经是1.2和1.3的天下了。SSLv3早就被弃用了，如果你还在用，赶紧升级——这不是建议，是警告。

TLS的核心流程，说白了就是两件事：身份验证和密钥协商。我画个简化的握手流程给你看：

Client                                      Server
  |                                           |
  |-------- ClientHello (支持的密码套件) ------->|
  |                                           |
  |<------- ServerHello (选定的密码套件) --------|
  |<------- Certificate (服务器证书) -----------|
  |<------- ServerHelloDone ------------------|
  |                                           |
  |-------- ClientKeyExchange (预主密钥) ------>|
  |-------- ChangeCipherSpec ----------------->|
  |-------- Finished ------------------------->|
  |                                           |
  |<------- ChangeCipherSpec -----------------|
  |<------- Finished -------------------------|
  |                                           |
  |=========== 加密通信开始 ===================|

嗯，这里要注意：TLS 1.3把握手从2-RTT优化到了1-RTT，甚至支持0-RTT。我在项目中遇到过一个问题——升级到TLS 1.3后，0-RTT虽然快，但存在重放攻击的风险。所以我的建议是：非幂等请求不要用0-RTT。

4.2 密码套件：选对武器很重要

密码套件就是一组加密算法的组合。你想想看，握手时客户端和服务端要商量好用什么算法来加密、用什么算法来做消息认证。常见的密码套件长这样：

TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
|      |      |        |         |
密钥交换 签名  对称加密  模式    哈希

我个人习惯用这个组合：ECDHE + RSA + AES-256-GCM + SHA384。为什么？ECDHE提供前向安全性，就算私钥泄露了，以前的会话也解不出来。AES-256-GCM是AEAD模式，加密和认证一步到位，性能也好。

4.3 证书管理：PKI的基石

证书是什么？说白了就是「我是谁」的官方证明。X.509证书里包含公钥、身份信息、有效期、签发者等信息。整个信任链长这样：

根CA (自签名)
  └── 中间CA (由根CA签发)
       └── 服务器证书 (由中间CA签发)
            └── 客户端证书 (可选，用于mTLS)

证书管理有几个关键点，我踩过的坑都列出来：

• 证书有效期：别设太长，90天是业界最佳实践。Let's Encrypt就是90天，自动续期。
• 私钥保护：私钥必须加密存储，权限最小化。我曾经见过有人把私钥放在Git仓库里...嗯，那场面。
• 证书吊销：用OCSP Stapling代替CRL，性能更好。OCSP Stapling由服务端主动查询吊销状态，客户端不用自己查。
• 证书链完整性：部署时要把中间证书和服务器证书一起发。很多新手只发了服务器证书，结果客户端验证失败。

4.4 mTLS双向认证：你也要证明你是谁

单向TLS只验证服务器身份，客户端不验证。但在微服务架构中，服务之间互相调用，你想想看——A服务调用B服务，B怎么知道A是合法的？这就是mTLS的用武之地。

mTLS的握手流程和单向TLS类似，但多了一步：

Client                                      Server
  |                                           |
  |-------- ClientHello --------------------->|
  |<------- ServerHello + 服务器证书 ----------|
  |<------- CertificateRequest (要求客户端证书)|
  |                                           |
  |-------- 客户端证书 + ClientCertificateVerify|
  |-------- ClientKeyExchange ---------------->|
  |-------- ChangeCipherSpec ----------------->|
  |-------- Finished ------------------------->|
  |                                           |
  |=========== 双向加密通信开始 ===============|

我在项目中遇到过一个问题：mTLS的证书管理成本很高。每个服务都要有自己的证书，而且证书过期了要重新签发。后来我们用了SPIFFE标准，配合Istio的Sidecar自动注入证书，才解决了这个问题。

4.5 实战：用Go实现mTLS

光说不练假把式。我写个简单的mTLS服务端和客户端示例：

服务端代码：

// 服务端加载证书和私钥
cert, err := tls.LoadX509KeyPair("server.crt", "server.key")
if err != nil {
    log.Fatal(err)
}

// 加载CA证书，用于验证客户端
caCert, _ := ioutil.ReadFile("ca.crt")
caCertPool := x509.NewCertPool()
caCertPool.AppendCertsFromPEM(caCert)

tlsConfig := &tls.Config{
    Certificates: []tls.Certificate{cert},
    ClientAuth:   tls.RequireAndVerifyClientCert,
    ClientCAs:    caCertPool,
    MinVersion:   tls.VersionTLS12,
}

listener, _ := tls.Listen("tcp", ":8443", tlsConfig)

客户端代码：

// 客户端加载自己的证书
cert, _ := tls.LoadX509KeyPair("client.crt", "client.key")

// 加载CA证书，验证服务端
caCert, _ := ioutil.ReadFile("ca.crt")
caCertPool := x509.NewCertPool()
caCertPool.AppendCertsFromPEM(caCert)

tlsConfig := &tls.Config{
    Certificates: []tls.Certificate{cert},
    RootCAs:      caCertPool,
    MinVersion:   tls.VersionTLS12,
}

conn, _ := tls.Dial("tcp", "server:8443", tlsConfig)

4.6 性能优化与最佳实践

TLS不是免费的午餐，它是有性能开销的。我总结了几条优化建议：

优化项	说明	效果
会话复用	复用TLS会话ID或Session Ticket	减少握手次数，提升50%+性能
OCSP Stapling	服务端主动提供证书吊销状态	减少客户端查询延迟
硬件加速	使用支持AES-NI的CPU	加密性能提升3-5倍
连接池	复用TCP连接，减少TLS握手	显著降低延迟
证书链优化	减少中间证书层级	减少握手数据量

最后说一句：安全是动态的。今天安全的算法，明天可能就被破解了。定期更新密码套件列表，关注安全公告，这是每个架构师的基本功。

好了，传输层安全就聊到这里。下一章我们聊聊应用层安全，看看JWT、OAuth2这些协议是怎么保护API的。