当前位置：首页 > article >正文

UCAS 24秋网络认证技术 CH10 SSL 复习

article 2025/1/7 14:06:08

TLS字段、参数含义
要了解每个消息是什么意思基本方式只验证服务端，服务端有证书，变形方式加上验证客户端
TLS1.3区别

协商过程

背景

Record层使用的各种加密算法参数，均由Handshake协议协商获得。

具体过程

随机数交换
- Client/Server相互发送随机数（以明文形式）。
算法选择
- 协商双方选择使用的加密算法。
公钥交换
- Server发送自己的公钥证书。
- Client验证该证书的有效性。
生成Premaster Secret
- Client生成Premaster Secret，并用Server的公钥加密后发送给Server。
- Server解密获取Premaster Secret。
密钥计算
- 双方基于共享的Premaster Secret和随机数，使用约定的算法计算出：
  - W Key（工作密钥）
  - IV（初始化向量）
  - MAC_Secret（消息认证密钥）

1. TLS1.2交互过程

1. 简单过程（ClientHello 和 ServerHello）

ClientHello：
- 包含以下信息：
  - 支持的最高协议版本。
  - 32字节随机数（4字节时间 + 28字节随机数）。
  - Session ID（用于Session重用，可选）。
  - 支持的密码算法列表（cipher suites）。
- 数据结构：
```
struct {
    uint32 gmt_unix_time;
    opaque random_bytes[28];
} Random;
```

ServerHello：

包含以下信息：
- 同样的32字节随机数。
- 选定的协议版本和算法（cipher suite，单个）。
- Session ID（同样可选）。

数据结构：

struct {
    ProtocolVersion server_version;
    Random random;
    SessionID session_id;
    CipherSuite cipher_suite;
    CompressionMethod compression_method;
} ServerHello;

2. Server端发送证书及确认

Certificate：
- Server端发送证书链，包含从Server证书到信任链开始的完整链。
- 包含Server的RSA公钥。
ServerHelloDone：
- Server端完成Hello阶段，等待Client的响应。

3. Client生成并发送密钥 (ClientKeyExchange)

Premaster Secret：

Client根据ServerHello选择的密钥协商算法生成。
生成的48字节Premaster Secret用Server证书公钥加密后发送。

数据结构：

struct {
    select (KeyExchangeAlgorithm) {
        case rsa: EncryptedPreMasterSecret;
        ...
    } exchange_keys;
} ClientKeyExchange;

共享的秘密信息：
- 共有以下三部分：
  - 32字节Client.random（ClientHello）。
  - 32字节Server.random（ServerHello）。
  - 48字节Premaster Secret（秘密）。

4. 生成Master Secret

基于Premaster Secret和随机数生成48字节Master Secret。

使用伪随机函数（PRF）：

master_secret = PRF(pre_master_secret, "master secret", 
                    ClientHello.random + ServerHello.random)[0..47];

5. 生成所需的密钥、IV、MAC Secret等

基于Master Secret、Client Random和Server Random生成：
- MAC Secret（消息认证密钥）。
- 工作密钥（Write Key）。
- IV（初始化向量）。

PRF计算：

key_block = PRF(SecurityParameters.master_secret, 
                "key expansion", 
                SecurityParameters.server_random + 
                SecurityParameters.client_random);

6. ChangeCipherSpec & Finished

ChangeCipherSpec：
- 客户端和服务器分别切换到协商好的加密算法及密钥。

Finished：

双方发送验证消息，表明握手完成：

verify_data = PRF(master_secret, finished_label, Hash(handshake_messages))[0..verify_data_length-1];

7. 最基本的Handshake协议流程总结

步骤总结：
1. Client → Server：ClientHello。
2. Server → Client：ServerHello, Certificate, ServerHelloDone。
3. Client → Server：ClientKeyExchange, [ChangeCipherSpec], Finished。
4. Server → Client：[ChangeCipherSpec], Finished。
5. 双方进入Application Data阶段。

基本变形1 - Client鉴别

变形1：Client鉴别

基本背景：
- 默认情况下，Client会利用Server证书对Server进行鉴别。
- 在支持双向认证的场景中，Server可以对Client进行鉴别。

流程

Server向Client请求证书：
- 在发送完Server证书之后，Server发送CertificateRequest消息。
- CertificateRequest中列出了Server接收的Client证书要求，包括：
  - 算法（如RSA、DSS等）。
  - 受信任的CA名称。
- 数据结构：
```
struct {
    ClientCertificateType certificate_types<1..2^8-1>;
    SignatureAndHashAlgorithm supported_signature_algorithms<2^16-1>;
    DistinguishedName certificate_authorities<0..2^16-1>;
} CertificateRequest;
```

Client响应：
- Client需要回复Certificate和CertificateVerify消息：
  - Certificate消息：包含Client的证书链，证明自己的身份。
```
struct {
    ASN.1Cert certificate_list<0..2^24-1>;
} Certificate;
```
  - CertificateVerify消息：
    - 对所有之前的Handshake消息进行数字签名（从ClientHello到当前消息，不包括本消息）。
    - 用于证明Client对所发送消息的完整性及其身份的真实性。
```
struct {
    digitally-signed struct {
        opaque handshake_messages[handshake_messages_length];
    };
} CertificateVerify;
```

验证流程：
- Server验证Client提交的证书是否可信，是否满足其在CertificateRequest中的要求。
- 确认Client身份后，完成后续Handshake过程。

总结

双向认证的场景主要通过Server对Client的证书请求与验证实现。
Client通过CertificateVerify消息提供对其身份及Handshake消息的数字签名，确保其认证信息的真实性和完整性。

变形2 - 不同类型证书/算法的影响

1. ClientHello

Client → Server：发送ClientHello消息。
- 包含随机数 (R_C)。
- 支持的协议版本、加密算法、压缩方法等信息。

2. ServerHello

Server → Client：发送ServerHello消息。
- 包含随机数 (R_S)。
- 确定的协议版本、加密算法、Session ID。

3. Server发送附加消息

Server根据需要发送以下消息：
- Certificate (可选)：发送Server证书链。
- ServerKeyExchange (可选)：在非RSA加密时发送，包含密钥交换所需的信息。
- CertificateRequest (可选)：请求Client提供证书（用于双向认证）。
- ServerHelloDone：表明Server完成Hello阶段，等待Client响应。

4. Client发送响应消息

Certificate (可选)：发送Client证书，用于证明其身份（双向认证）。
ClientKeyExchange：发送密钥交换信息（例如，Premaster Secret加密数据）。
CertificateVerify (可选)：对之前的Handshake消息进行签名，用于验证Client身份。

5. ChangeCipherSpec & Finished

Client → Server：
- ChangeCipherSpec：通知切换到加密通信。
- Finished：发送加密的验证消息，表明握手完成。
Server → Client：
- ChangeCipherSpec：通知切换到加密通信。
- Finished：发送加密的验证消息，表明握手完成。

6. 加密的Application Data阶段

双方开始加密通信，传输实际的应用数据。
所有后续数据都受到握手中协商的加密算法和密钥的保护。

重要说明

带星号 (*) 的步骤为可选。
ChangeCipherSpec和Finished标志着切换到加密通信阶段。
握手完成后，所有通信均加密。

变形3 - Session重用

Session重用的背景

Session重用机制旨在提高TLS协议的效率，避免重新协商所有参数。
使用Session ID来标识和重用之前的会话。

1. 第一次协商会话

在首次TLS握手协商时：
- ServerHello中会给出一个Session ID。
- 如果Server不想支持Session重用，则不会提供Session ID。
- 双方完成会话协商后，传输一定的Application Data后，断开连接。

2. 第二次会话中Client发起重用

ClientHello：
- 在第二次会话中，Client在ClientHello中携带上次的Session ID，表示希望重用Session。
- 如果Client不希望重用Session，则在ClientHello中不提供Session ID。

3. Server处理Client的重用请求

ServerHello：
- Server接收到带有Session ID的ClientHello后，会查找自己的缓存：
  - 如果找到与该Session ID对应的Session，并且Server允许重用：
    - 在返回的ServerHello中携带相同的Session ID，表示同意重用。
    - 跳过完整握手过程，直接切换到加密算法，通过发送ChangeCipherSpec和Finished消息完成重用过程。
  - 如果未找到或不允许重用：
    - Server返回一个新的Session ID，表示重新协商。