3、TLS/SSL协议原理：握手协议、记录协议、证书链验证、TLS 1.3新特性
各位同学好，我是老张。今天咱们聊聊TLS/SSL协议。说实话，这玩意儿是PIS系统的命脉。没有它，你传输的乘客信息、列车控制指令，就跟在大街上喊话一样，谁都能听。
我刚开始接触PIS系统时，有个项目就因为通信加密没做好，被第三方截获了报文。虽然没造成大事故，但领导的脸都绿了。从那以后，我对TLS的每个细节都格外较真。
3.1 握手协议：建立信任的第一步
握手协议，说白了就是客户端和服务器互相认识的过程。我习惯把它比作两个陌生人见面——先亮身份，再商量怎么说话。
握手流程大致分四步：
- ClientHello：客户端发个招呼，告诉服务器自己支持哪些TLS版本、加密套件。
- ServerHello：服务器挑一个双方都支持的版本和套件，发回自己的证书。
- 证书验证与密钥交换：客户端验证服务器证书，然后双方协商出一个对称密钥。
- Finished：双方确认握手完成，开始加密通信。
嗯，这里要注意。握手阶段是明文传输的，只有协商出密钥后才加密。所以证书的真实性至关重要。我在项目中遇到过有人伪造证书，结果整个通信链路都被监控了。
核心要点：握手协议的核心是身份认证和密钥协商。没有这一步，后面的加密就是空中楼阁。
3.2 记录协议：数据的分装与加密
握手完成后，就轮到记录协议上场了。它的工作很简单——把应用层的数据切块、压缩（可选）、加密、加MAC，然后发出去。
记录协议的格式是这样的：
struct {
ContentType type; // 内容类型（握手、警报、应用数据等）
ProtocolVersion version; // 协议版本
uint16 length; // 数据长度
opaque fragment[TLSPlaintext.length]; // 加密后的数据
} TLSPlaintext;你想想看，每个记录都是独立加密的。这意味着即使攻击者截获了某个记录，也无法解密其他记录。我有个朋友在PIS项目中，就因为没理解这个机制，把多个记录拼在一起加密，结果解密时全乱了。
记录协议还负责数据完整性校验。每个记录都带一个MAC（消息认证码），接收方会验证它。如果MAC对不上，说明数据被篡改了。我曾经调试过一个PIS系统，发现偶尔丢包，最后查出来是MAC计算时用了错误的密钥。
个人经验：记录协议的性能瓶颈往往在加密和MAC计算上。如果PIS系统需要高吞吐量，建议使用硬件加速或选择轻量级加密套件。
3.3 证书链验证：信任的传递
证书链验证，说白了就是看服务器证书是不是靠谱的。我习惯把它比作身份证——你不仅要看身份证本身，还要看发证机关是不是公安局。
验证过程是这样的：
- 服务器发来证书，客户端检查证书是否过期、是否被吊销。
- 客户端用CA的公钥验证证书签名。
- 如果证书是中间CA签发的，客户端会继续验证中间CA的证书，直到根CA。
- 根CA证书必须预装在客户端信任库中。
这里有个坑。很多PIS系统为了省事，直接跳过证书验证。我曾经见过一个项目，服务器用的是自签名证书，客户端也没验证，结果中间人攻击轻松得手。嗯，这绝对是个反面教材。
避坑指南：我曾经在PIS项目中遇到证书链不完整的问题。服务器只发了自己的证书，没发中间CA证书，客户端验证失败。解决方案是确保服务器发送完整的证书链。
证书链验证的另一个关键是CRL（证书吊销列表）或OCSP（在线证书状态协议）。如果证书被吊销了，但客户端没检查，那这个证书依然会被信任。我建议PIS系统至少实现OCSP Stapling，这样服务器会主动提供证书状态，减少客户端的查询开销。
3.4 TLS 1.3新特性：更快、更安全
TLS 1.3是2018年发布的，相比1.2，变化非常大。我刚开始用1.3时，还不太习惯，但用久了就回不去了。
主要新特性有这些：
| 特性 | 说明 | 我的评价 |
|---|---|---|
| 握手简化 | 从1.2的2-RTT降到1-RTT，甚至0-RTT | PIS系统响应更快了 |
| 移除不安全算法 | 不再支持RC4、3DES、CBC模式等 | 省心，不用纠结选哪个 |
| 前向安全性 | 所有密钥交换都必须用ECDHE或DHE | 即使私钥泄露，历史数据也安全 |
| 0-RTT | 允许在第一次握手时发送数据 | 小心重放攻击 |
0-RTT是个好东西，但也容易出问题。我有个项目用了0-RTT，结果因为重放攻击，导致PIS系统收到了重复的指令。解决方案是在应用层加序列号或时间戳。
TLS 1.3的握手流程也变了。它把ServerHello和证书、密钥交换合并到一个消息里，减少了交互次数。你想想看，对于PIS系统这种需要频繁建立连接的场景，1-RTT能省多少时间。
核心要点：TLS 1.3的握手更快、更安全，但0-RTT需要谨慎使用。我建议PIS系统优先使用1.3，但保留1.2作为降级选项。
3.5 实践建议
说了这么多，最后给点实操建议：
- 选对加密套件：优先用TLS_AES_128_GCM_SHA256或TLS_AES_256_GCM_SHA384。别用那些过时的。
- 证书管理：证书过期前一个月就要提醒更换。我见过PIS系统因为证书过期，整个通信瘫痪的。
- 性能优化：如果PIS系统需要高并发，考虑用会话复用或TLS 1.3的0-RTT。
- 日志记录：记录TLS握手失败的原因，方便排查问题。
好了，这一章就到这里。TLS/SSL协议看起来复杂，但核心就是握手、记录、验证这三件事。搞懂了它们，PIS系统的通信安全就有了保障。