详解SSL/TLS协议握手协议、记录层协议与警报协议

传输层安全

SSL/TLS协议

简介

SSL/TLS 是一种密码通信框架，是世界上使用最广泛的密码通信方法

• SSL：安全套接层，与1994年由网景公司设计
• TLS：基于SSL3.0发展而来，相当于SSL的后续版本

SSL/TLS综合运用了密码学中的对称密码，消息认证码，公钥密码，数字签名，伪随机数生成器等，可以说是密码学中的集大成者。

设计原则

• 分层协议架构
  • 握手协议：负责实现密钥交换与认证
  • 记录层协议：用来安全传输数据
  • 加密规约修改协议：启用新的密码参数
  • 报警协议：报警和错误
• 应用协议独立性
  • 支持HTTP、SMTP等多种上层协议（比如HTTPS=HTTP+TLS）
  • 不限制应用层安全逻辑，仅提供传输层安全保护
• 核心逻辑
  • 协商密钥交换算法->身份认证（PKI证书）->协商密钥->数据加密传输

核心密码学算法与概念

• 对称加密算法（记录层协议的核心）
  • AES 128/192/256，TLS 1.2+支持GCM/CBC模式，GCM模式更加安全
  • ChaCha20：流加密，TLS 1.3新增，低资源消耗
  • 3DES：在TLS 1.3 被移除
• 非对称加密算法（用于密钥交换与签名）
  • RSA：基于大整数分解困难问题，TLS 1.2支持密钥交换与签名，TLS 1.3中仅支持签名（不具有前向安全）
  • ECC系列 ：
    • ECDSA：椭圆曲线签名，TLS 1.3推荐
    • ECDHE：椭圆曲线瞬时DH（具有前向安全）
• HASH与MAC算法（保证完整性）
  • SHA-2
  • HMAC：基于Hash的消息认证码
  • TLS 1.3中用AEAD整合加密与MAC
• 密钥派生函数KDF
  • 基于HMAC，从共享密钥中派生会话密钥
  • 流程：提取原始密钥作为原料->派生多用途密钥
• 前向安全 ：确保即使长期使用的密钥在未来泄露，也不危及过去的通信内容
  • 核心思想：使用一次性的会话密钥，每次通信都使用临时生成的密钥进行加密，用完就丢弃

记录协议

• 建立在TCP基础之上，功能：

  • 对上：提供透明的安全服务，接收任意长度的数据流，不关心内容含义
  • 对下：输出统一格式的、长度受限的、加密后的数据块

• 根据当前会话状态给出压缩算法，CipherSpec给出对称加密算法、MAC算法、密钥长度、Hash长度、IV长度，以及连接状态中给出的Client和Server的随机数、加密密钥、MAC秘密值、IV和消息序列号等，对将要传送的数据实施以下操作：

  • 压缩/解压
  • 加密/解密
  • MAC计算/MAC校验

  

发方的处理流程

1. 分片：从上层接收任意长度的数据流，将其分为16K或者更小的数据块
2. 无损压缩（可选）：用当前会话状态中给出的压缩算法，将明文结构的SSLPlaintext压缩为压缩记录SSLCompressed
3. MAC计算：对SSLCompressed计算消息摘要
4. 加密：用加密算法加密压缩消息和消息摘要，形成密文结构SSLCiphertext
   1. 3 4步有3种选择：
      1. MAC-then-Encrypt：先计算MAC，再和压缩值/明文M一起进行加密
      2. Encrypted-then-MAC：先加密，对密文计算MAC，最终得到MAC+Cipher
      3. AEAD：加密与认证一体化，比如AES-GCM就是这样的
5. 封装发送：将数据封装为TCP数据报文并发送

收方的处理流程

与发方相反

1. 从TCP报文中提取密文
2. 解密与验证
3. 解压缩
4. 重组为明文消息

记录协议中的收发双方：

收发双方的共享密钥

以C/S架构，分为客户端写密钥和服务端写密钥；这样区分的目的是为了让消息的方向可区分，防止反射攻击

• 客户端写密钥：当客户端作为发方时的密钥，即客户端加密，服务端解密，可分为以下3类
  • 写密钥：对明文进行加密
  • 写MAC密钥：用于HMAC算法，计算消息摘要时使用的密钥；即客户端创建MAC，服务端验证MAC
  • 写IV：客户端在分组加密（CBC）时使用的IV向量，服务端用于解密
• 服务端写密钥：当服务端作为发方时的密钥，即服务端加密，客户端解密，可分为以下3类
  • 写密钥：对明文进行加密
  • 写MAC密钥：用于HMAC算法，计算消息摘要时使用的密钥，即服务端创建MAC，客户端验证MAC
  • 写IV：服务端在分组加密（CBC）时使用的IV向量，客户端用于解密

警报协议

协议格式，由Level消息和Alert消息组成，被加密传输

、

根据错误程度，警报消息会被分为两类：

• Level=1：警告消息
• Level=2：致命消息，连接会被立即中止，并且会话标识符作废

根据功能可分为：

• Close_Notify
• Alert_Error

二者都是关闭连接，但是区别在于：

• 前者属于警告消息，连接可以恢复
• 后者属于致命消息，连接标识符已作废，不可恢复

握手协议

报文格式

由消息类型（1字节）+长度（3字节）+消息内容（n字节）组成

阶段

通过2个RTT完成

阶段1：建立安全功能

• Client Hello：客户端请求与服务端进行安全通信
  • TLS版本
  • 随机数client_random
  • 会话ID session_id
  • 可选的加密套件cipher_suites:
    • 密码套件格式为：TLS_密钥交换算法_WITH_加密算法_MAC算法
  • 可选的压缩方法
• Server Hello：
  • TLS版本
  • 随机数client_random
  • 会话ID session_id
  • 选择的加密套件cipher_suites:
    • 密码套件格式为：TLS_密钥交换算法_WITH_加密算法_MAC算法
  • 选择的压缩方法

阶段2、3：认证与密钥交换

常见的公钥密码算法：

算法	加密/解密	数字签名	密钥交换
RSA	是	是	是
椭圆曲线	是	是	是
DH	否	否	是
DSS	否	是	否

握手协议中支持4种密钥交换算法：RSA、固定DH，瞬时DH，匿名DH

密码学前置知识：DH密钥交换：参数为大素数p与生成元g

• 对于交换双方C，S，本地分别生成一个临时私钥a,b

• 随即分别生成临时公钥A=g^a mod p,B=g^b mod p

• 然后交换公钥，计算出共享密钥S=A^b mod p = B^a mod p = g^{ab} mod p

• RSA密钥交换

  • 核心逻辑：客户端产生预主密钥，通过服务端的RSA公钥加密后同步到对方，服务端使用自己的RSA私钥进行解密
  • 认证：服务端强制提供RSA证书供客户端认证，客户端可选提供RSA证书
  • 前向安全性：无，一旦服务端私钥被盗，预主密钥就暴露了，会导致历史会话被破解
  • 握手过程：
    • certificate：服务端的RSA证书链，包含服务端公钥 ，CA签名，证书有效期以及密钥用途="密钥加密"
      • 客户端验证：证书链是否可信，证书是否过期/被吊销，公钥用途合法
    • server_key_exchange：不需要
    • certificate_request：可选，若选择则客户端需要提供自己的证书
    • certificate：当certificate_request被选择；客户端的RSA证书
    • client_key_exchange：客户端生成16字节长的预主密钥，用服务端公钥加密后发送给服务端
    • certificate_verify：可选
  • 若选择了certificate_request，客户端需要额外提供：
    • certificate：客户端的RSA证书，服务端验证该证书链是否可信
    • certificate_verify：用客户端私钥签名握手摘要，服务端使用客户端公钥验证签名

• 固定DH密钥交换

  • 核心逻辑：客户端与服务端基于各自的静态DH密钥对，协商共享预主密钥
  • 认证：服务端强制提供DH证书，客户端可选认证
  • 前向安全性：无，服务端使用长期静态DH公钥
  • 握手过程：
    • certificate：服务端的DH证书链，包含服务端DH公钥 ，DH参数p和g（大素数与生成元），CA签名，证书有效期以及密钥用途="密钥协商"
      • 客户端验证：证书链可信，证书未过期/被吊销，DH参数合法，密钥用途合法
    • server_key_exchange：不需要
    • certificate_request：可选，可接受的CA列表，支持的客户端认证算法
    • certificate：当certificate_request被选择；客户端的DH证书
      • 服务端验证：证书链可信，DH参数与服务端兼容
    • client_key_exchange：客户端静态DH公钥（若证书中未包含，需要显式发送）
      • 预主密钥计算：g^{服务端私钥}*客户端公钥 mod p，仅需交换公钥
    • certificate_verify：可选；用客户端DH私钥签名握手消息摘要
      • 服务端验证：验证客户端持有DH私钥，身份合法

• 瞬时DH密钥交换（DHE）

  • 核心逻辑：客户端与服务端基于临时DH密钥对，协商共享预主密钥 ，身份依赖于独立证书而非DH证书
  • 认证：服务端强制提供RSA/DSA证书，客户端可选认证
  • 前向安全性：有，每次会话生成临时DH密钥对，会话结束后销毁，私钥泄露不影响历史会话
  • 握手过程：
    • certificate：服务端的RSA/DSA证书链，包含服务端公钥 ，CA签名，证书有效期以及密钥用途="密钥协商"
      • 客户端验证：证书链可信，证书未过期/被吊销，密钥用途合法
    • server_key_exchange：包含以下内容
      • DH的参数：大素数p和生成元g
      • 临时DH公钥：b*g mod p
      • 签名：使用服务器的私钥对DH参数、临时DH公钥以及Client/Server Hello的消息摘要进行签名
    • certificate_request：可选，可接受的CA列表，支持的客户端认证算法
    • certificate：当certificate_request被选择；客户端的RSA/DSA证书
      • 服务端验证：证书链可信，证书未过期/被吊销
    • client_key_exchange：客户端临时DH公钥a*g mod p
      • 共享预主密钥计算：a*b*g mod p，仅需交换公钥
    • certificate_verify：可选；用客户端DH私钥签名DH参数、临时DH公钥、握手消息摘要
      • 服务端验证：验证客户端持有DH私钥，身份合法
  • 小结：
    • 与固定DH的区别：使用临时DH密钥对，会话结束销毁，具有前向安全性
    • 服务器认证的双重保证：
      • 证书验证身份合法性
      • server_key_exchange用服务器私钥签名认证DH参数与临时公钥未被篡改

• 匿名DH密钥交换（ADH）

  • 核心逻辑：客户端与服务端基于临时DH密钥对，协商共享预主密钥 ，无身份认证，易受到中间人攻击
  • 认证：无
  • 前向安全性：有，每次会话生成临时DH密钥对，会话结束后销毁
  • 现状：在TLS1.3中被移除，TLS1.2支持，但极少使用
  • 握手过程：
    • sever_key_exchange：
      • DH参数与服务端临时DH公钥
    • client_key_exchange
      • 客户端临时DH公钥

匿名的代价：由于无身份认证，攻击者可作为中间人拦截临时DH公钥，从而窃取预主密钥；而RSA、固定DH、DHE密钥协商因为需要服务端提供证书证明身份，因此可以抵御中间人攻击

应用场景：无需身份认证但需要加密传输，比如公共WIFI

第4阶段：完成

由两条消息组成：

• change_cipher_spec:该消息已不是握手协议，而是修改密码规范协议发送；表明在这之后的消息都使用协商好的密钥进行加密
• finished：对前面所有的握手消息用协商好的密钥进行签名，有两个作用
  • 验证握手过程未被篡改
  • 验证发送方拥有正确的密钥