TLS 1.3 套件集
TLS 1.3 精简了套件命名：套件只描述对称加密与哈希算法，不再包含密钥交换方式与证书类型，后两者改由扩展协商。标准共定义 5 个套件，其中 3 个常用（AES-128-GCM、AES-256-GCM、ChaCha20-Poly1305），另外 2 个是面向受限环境的 CCM 套件。相比 TLS 1.2 动辄上百个套件，可配置面小得多。
基本信息
| 常用套件 | TLS_AES_128_GCM_SHA256、TLS_AES_256_GCM_SHA384、TLS_CHACHA20_POLY1305_SHA256 |
|---|---|
| 受限环境 | TLS_AES_128_CCM_SHA256、TLS_AES_128_CCM_8_SHA256 |
| 命名含义 | 前半部分是对称算法，后缀是哈希算法 |
| 不包含 | 密钥交换与认证方式在扩展中另行协商 |
| 配置位置 | Nginx 需用 ssl_conf_command 设置 TLS 1.3 套件 |
TLS 1.3 套件
| 套件名 | 加密 | 哈希 | 备注 |
|---|---|---|---|
| TLS_AES_128_GCM_SHA256 | AES-128-GCM | SHA-256 | 通用默认 |
| TLS_AES_256_GCM_SHA384 | AES-256-GCM | SHA-384 | 更高强度 |
| TLS_CHACHA20_POLY1305_SHA256 | ChaCha20-Poly1305 | SHA-256 | 无 AES 加速环境 |
| TLS_AES_128_CCM_SHA256 | AES-128-CCM | SHA-256 | 受限设备 |
| TLS_AES_128_CCM_8_SHA256 | AES-128-CCM-8 | SHA-256 | 标签 8 字节，IoT 场景 |
典型使用场景
- 服务端加固：明确允许的套件集合，避免遗留弱算法掺入
- 移动端优化：为无 AES 硬件加速的设备保留 ChaCha20 套件
- IoT 场景：受限设备使用 CCM 套件并评估标签长度带来的强度变化
- 抓包排查：从握手记录中确认实际选中的套件与协议版本
- 性能对比：不同套件在目标硬件上的吞吐差异需要实测而不是推断
指定套件测试
指定套件测试
# 只允许 ChaCha20 套件，观察服务端是否接受
openssl s_client -connect example.com:443 -tls1_3 -ciphersuites TLS_CHACHA20_POLY1305_SHA256 </dev/null | grep Cipher
# 查看握手使用的协议版本与套件
openssl s_client -connect example.com:443 -tls1_3 </dev/null 2>&1 | grep -iE 'Ciphersuite|Protocol'
# 指定 TLS 1.3 并限制密钥交换组
openssl s_client -connect example.com:443 -tls1_3 -groups X25519 </dev/nullTLS 1.3 套件不包含密钥交换与认证信息，服务端证书类型与曲线在扩展中单独协商。
配置位置容易出错：Nginx 的 ssl_ciphers 只影响 TLS 1.2 及更早版本，TLS 1.3 套件需要通过 ssl_conf_command 这类指令设置。
CCM_8 的认证标签只有 8 字节，完整性强度低于标准版本，只适合链路可靠且资源紧张的受限场景，不应作为通用选择。
TLS 1.3 的套件数量少，选择逻辑反而更简单：无特殊需求时按服务端硬件能力在 AES-GCM 与 ChaCha20 之间排序即可，不必逐条枚举。
巡检时把协商结果留档：协议版本与套件组合记录下来，日后出现兼容性或性能争议时可以直接对比，而不必凭印象回忆。