2026-04-23 05:42:16 网络安全文章来源：ZONE.CI 全球网 0 阅读模式

文章总结： 本文系统介绍了TLCP、SSH和TLS协议的密码套件协商机制，重点解析了国密标准GB/T38636-2020和GM/T0129-2023的算法规范。核心揭示了客户端推荐、服务端选择的协商原则，详细对比了GCM与CBC模式的安全性差异，并通过两道实战题目演示了具体协商过程。文档提供了完整的密码套件命名规则、版本标识格式等关键技术要点，具备较强的实践指导价值。 综合评分： 85 文章分类： 技术标准,网络安全,应用安全,安全工具,安全培训

cover_image

TLCP & SSH 密码套件协商实战练习题

原创

利刃信安利刃信安

利刃信安

2026年4月22日 00:02 北京

在小说阅读器读本章

去阅读

TLCP & SSH 密码套件协商实战练习题

协议背景

TLCP 协议简介

TLCP（Transport Layer Cryptography Protocol，传输层密码协议）是中国国家标准，定义于 GB/T 38636-2020《信息安全技术传输层密码协议》，于2020年4月28日发布，2020年11月1日实施。本标准由全国信息安全标准化技术委员会(SAC/TC260)提出并归口。

TLCP协议利用密码技术，为两个应用程序之间提供保密性和数据的完整性。协议用到的密码算法包含非对称密码算法、分组密码算法、密码杂凑算法、数据扩展函数和伪随机函数。

协议组成：

• 记录层协议：接收将要被传输的消息，将数据分块、压缩(可选)、计算HMAC、加密，然后传输
• 握手协议族：包含密码规格变更协议、报警协议及握手协议

协议版本： TLCP 1.1（版本号 0x0101）

SSH 协议简介

SSH（Secure Shell）协议定义于 RFC 4253，是一种在不安全网络上提供安全远程登录和其他安全网络服务的协议。GM/T 0129-2023《SSH密码协议规范》 于2023年12月4日发布，2024年6月1日实施，在SSH协议基础上增加了国密算法支持。

协议框架：

• 传输层协议：提供服务端鉴别、机密性和完整性
• 鉴别协议：用于服务端鉴别客户端用户身份
• 连接协议：用于将加密通道复用为若干逻辑信道

协议版本： CSSH 1.0（版本标识格式：CSSH-1.0-<软件版本号>[ <注释>]）

版本标识字符串格式（GM/T 0129-2023）：

CSSH-<protoversion>-<softwareversion>[SP<comments>]CR LF

• CSSH：本文件的简称
• <protoversion>：协议版本号，固定为 1.0
• <softwareversion>：软件名称和版本号，由实现者定义，不可含有空格和减号
• <comments>：可选注释字段
• 示例：CSSH-1.0-MySSH3.3 This is comment CR LF

TLS 协议简介

TLS（Transport Layer Security，传输层安全协议）是国际标准的安全传输协议：

• TLS 1.2（RFC 5246，2008年8月）：当前广泛使用的版本
• TLS 1.3（RFC 8446，2018年8月）：最新版本，简化了握手流程，强制使用前向安全性

TLS 1.3 主要改进：

• 握手从2-RTT减少到1-RTT（甚至0-RTT）
• 移除了不安全的算法（RSA密钥交换、CBC模式、RC4、MD5、SHA-1）
• 强制使用前向安全性（ECDHE/DHE）
• 加密更多握手信息（ServerHello之后全部加密）

密码套件协商核心原则

根据协议规范，无论是SSH、TLCP还是TLS，密码算法/套件的协商都遵循**”客户端推荐（按优先级排序），服务端选择（匹配自身支持列表中的首个）”**的核心原则：

TLCP（GB/T 38636-2020 第19页）：

“客户端应按照密码套件使用的优先级顺序排列，优先级最高的密码套件应排在首位。服务端将在密码套件列表中选择一个与之匹配的密码套件，如果没有可匹配的密码套件，应返回握手失败报警消息 handshake_failure 并且关闭连接。”

SSH（RFC 4253 Section 7.1）：

“The chosen encryption algorithm to each direction MUST be the first algorithm on the client’s name-list that is also on the server’s name-list.”

GM/T 0129-2023 第12页 8.5.1：

“双方发送支持的算法名称列表。名称列表中的第一个为首选算法。双方在列表中选择第一个与对方达成一致的算法作为密钥协商算法。”

TLS 1.2（RFC 5246 Section 7.4.1.2）：

“The cipher suite list, in the client hello message, is used by the client to show the cipher suites it supports. The cipher suites should be listed in order of preference. The server will select a cipher suite from the list.”

TLS 1.3（RFC 8446 Section 4.1.2）：

“The client sends a ClientHello message containing a list of symmetric cipher/HKDF hash pairs. The server processes the ClientHello and determines the appropriate cryptographic parameters for the connection.”

知识要点

TLCP 密码套件命名规范

TLCP密码套件命名格式为：密钥交换算法_对称加密算法_加密模式_完整性校验算法

算法实现说明（GB/T 38636-2020 第19页）：

• 本标准实现 ECC 和 ECDHE 的算法为 SM2（GB/T 32918）
• 本标准实现 IBC 和 IBSDH 的算法为 SM9（GM/T 0044-2016）

GCM 与 CBC 模式对比

GB/T 38636-2020 定义的密码套件（第19页表2）

| 名称 | 密钥交换 | 加密 | 效验 | 值 | | — | — | — | — | — | | ECDHE_SM4_CBC_SM3 | ECDHE | SM4_CBC | SM3 | {0xe0,0x11} | | ECDHE_SM4_GCM_SM3 | ECDHE | SM4_GCM | SM3 | {0xe0,0x51} | | ECC_SM4_CBC_SM3 | ECC | SM4_CBC | SM3 | {0xe0,0x13} | | ECC_SM4_GCM_SM3 | ECC | SM4_GCM | SM3 | {0xe0,0x53} | | IBSDH_SM4_CBC_SM3 | IBSDH | SM4_CBC | SM3 | {0xe0,0x15} | | IBSDH_SM4_GCM_SM3 | IBSDH | SM4_GCM | SM3 | {0xe0,0x55} | | IBC_SM4_CBC_SM3 | IBC | SM4_CBC | SM3 | {0xe0,0x17} | | IBC_SM4_GCM_SM3 | IBC | SM4_GCM | SM3 | {0xe0,0x57} | | RSA_SM4_CBC_SM3 | RSA | SM4_CBC | SM3 | {0xe0,0x19} | | RSA_SM4_GCM_SM3 | RSA | SM4_GCM | SM3 | {0xe0,0x59} | | RSA_SM4_CBC_SHA256 | RSA | SM4_CBC | SHA256 | {0xe0,0x1c} | | RSA_SM4_GCM_SHA256 | RSA | SM4_GCM | SHA256 | {0xe0,0x5a} |

GM/T 0129-2023 定义的加密算法（第10-11页表4）

| 算法名称 | 描述 | 可选/必选 | | — | — | — | | SM4-CBC | SM4算法CBC工作模式 | 必选 | | SM4-CFB | SM4算法CFB工作模式 | 可选 | | SM4-CTR | SM4算法CTR工作模式 | 可选 | | SM4-OFB | SM4算法OFB工作模式 | 可选 | | SM4-CCM | SM4算法CCM工作模式，为可鉴别加密模式 | 可选 | | SM4-KW | SM4算法Key Wrap工作模式，为可鉴别加密模式 | 可选 | | SM4-GCM | SM4算法GCM工作模式，为可鉴别加密模式 | 可选 |

密钥交换算法与证书密钥类型关系（GB/T 38636-2020 第20页表3）

SSH 扩展协商机制（RFC 8308）

RFC 8308 定义了SSH协议的扩展协商机制，通过 SSH_MSG_EXT_INFO 消息实现：

扩展协商流程：

1. 客户端在 SSH_MSG_KEXINIT 的 kex_algorithms 字段中添加 ext-info-c
2. 服务端在 SSH_MSG_KEXINIT 的 kex_algorithms 字段中添加 ext-info-s
3. 密钥交换完成后，接收方发送 SSH_MSG_EXT_INFO 消息
4. 扩展信息包含扩展名称和扩展数据

已定义的扩展：

GM/T 0129-2023 扩展支持：

• 支持 server-sig-algs 扩展，用于协商SM2签名算法

TLS 1.3 密码套件（RFC 8446）

TLS 1.3 密码套件格式简化，不再包含密钥交换算法（因为强制使用ECDHE/DHE）：

| 密码套件名称 | 值 | | — | — | | TLS_AES_128_GCM_SHA256 | {0x13,0x01} | | TLS_AES_256_GCM_SHA384 | {0x13,0x02} | | TLS_CHACHA20_POLY1305_SHA256 | {0x13,0x03} | | TLS_AES_128_CCM_SHA256 | {0x13,0x04} | | TLS_AES_128_CCM_8_SHA256 | {0x13,0x05} |

TLS 1.3 与 TLS 1.2 密码套件对比：

| 对比项 | TLS 1.2 | TLS 1.3 | | — | — | — | | 密钥交换 | 包含在套件中（RSA/ECDHE/ECDH） | 不包含，单独协商 | | 加密模式 | CBC、GCM、CCM等 | 仅AEAD（GCM、CCM、ChaCha20） | | HMAC | 显式指定 | 隐含在AEAD中 | | RSA密钥交换 | 支持 | 不支持 | | CBC模式 | 支持 | 不支持 |

题目一：TLCP 密码套件协商

【背景描述】

某国密合规系统（遵循 GB/T 38636-2020 标准）进行双向握手连接。客户端在 ClientHello 消息中发送了密码套件列表，服务端根据自身的安全策略配置进行匹配选择。

请根据以下列表信息，分析最终选定的密码套件。

【已知条件】

1. 客户端发送的密码套件列表（ClientHello.cipher_suites，按优先级从高到低排列，共5个）：

• ECDHE_SM4_GCM_SM3 (值: {0xe0,0x51})
• ECC_SM4_GCM_SM3 (值: {0xe0,0x53})
• ECC_SM4_CBC_SM3 (值: {0xe0,0x13})
• ECDHE_SM4_CBC_SM3 (值: {0xe0,0x11})
• RSA_SM4_CBC_SM3 (值: {0xe0,0x19})

2. 服务端本地支持的密码套件配置（共5个）：

• ECC_SM4_CBC_SM3 (值: {0xe0,0x13})
• RSA_SM4_CBC_SM3 (值: {0xe0,0x19})
• ECDHE_SM4_CBC_SM3 (值: {0xe0,0x11})
• IBC_SM4_CBC_SM3 (值: {0xe0,0x17})
• RSA_SM4_GCM_SHA256 (值: {0xe0,0x5a})

注：由于硬件密码机限制，该服务端当前配置不支持以 ECDHE 进行密钥交换的 GCM 模式套件。

【问题】

服务端最终在 ServerHello 消息中选择的密码套件是哪一个？如果协商失败，请说明原因。

题目二：SSH 协议加密算法协商

【背景描述】

在一次安全审计中，抓取到了一次 SSH 连接建立的握手数据包。通过解析 SSH_MSG_KEXINIT 消息，获取到了客户端与服务端各自声明的加密算法列表。请根据以下列表信息，分析并回答最终协商选定的加密算法。

【已知条件】

1. 客户端支持的加密算法列表（按优先级从高到低排列，共5个）：

• [email protected]
• [email protected]
• aes256-ctr
• aes192-ctr
• sm4-ctr

2. 服务端支持的加密算法列表（按优先级从高到低排列，共5个）：

• aes256-ctr
• sm4-gcm
• aes128-ctr
• sm4-ctr
• aes256-cbc

【问题】

根据 SSH 协议规范（RFC 4253 及 GM/T 0129-2023），最终协商选定的加密算法是哪一个？请简述分析过程。

题目一解析 (TLCP)

【正确答案】

最终选定的密码套件是：ECC_SM4_CBC_SM3（值为 {0xe0,0x13}）。

【解析过程】

根据 GB/T 38636-2020 标准（第19页），服务端收到客户端密码套件列表后，会按照客户端的优先级顺序依次遍历，选择第一个自己支持的套件。标准原文规定：

“服务端将在密码套件列表中选择一个与之匹配的密码套件，如果没有可匹配的密码套件，应返回握手失败报警消息 handshake_failure 并且关闭连接。”

逐项检查：

| 序号 | 客户端套件 | 服务端是否支持 | 结果 | | — | — | — | — | | 1 | ECDHE_SM4_GCM_SM3 | ❌ 不支持（服务端配置中无此套件） | 匹配失败 | | 2 | ECC_SM4_GCM_SM3 | ❌ 不支持（服务端配置中无此套件） | 匹配失败 | | 3 | ECC_SM4_CBC_SM3 | ✅ 支持（服务端列表第1位） | 匹配成功 |

详细分析：

1. 检查客户端第1个套件：ECDHE_SM4_GCM_SM3

• 服务端支持列表：{ECC_SM4_CBC_SM3, RSA_SM4_CBC_SM3, ECDHE_SM4_CBC_SM3, IBC_SM4_CBC_SM3, RSA_SM4_GCM_SHA256}
• 匹配结果：未找到，服务端不支持 ECDHE 密钥交换的 GCM 模式套件
• 状态：继续检查下一个

2. 检查客户端第2个套件：ECC_SM4_GCM_SM3

• 服务端支持列表：同上
• 匹配结果：未找到，服务端不支持 ECC 密钥交换的 GCM 模式套件
• 状态：继续检查下一个

3. 检查客户端第3个套件：ECC_SM4_CBC_SM3

• 服务端支持列表：同上
• 匹配结果：找到，该套件位于服务端列表第1位
• 状态：匹配成功，停止查找

【结论】

虽然客户端最偏好 ECDHE 密钥交换与 GCM 认证加密模式（提供前向安全性和更高的性能），但由于服务端硬件密码机限制，不支持这两种组合。协商最终”降级”为客户端列表中第3个选项 ECC_SM4_CBC_SM3。

服务端将在 ServerHello 消息中返回该套件的值 {0xe0,0x13}，握手继续进行。

【安全说明】

• ECC_SM4_CBC_SM3 使用 ECC（基于SM2证书）密钥交换，不提供前向安全性
• CBC 模式需要额外的 HMAC-SM3 提供完整性保护
• 在实际部署中，建议服务端升级硬件以支持 ECDHE_GCM 套件，获得更好的安全性
• 参考 TLS 1.3 的做法，应优先使用 ECDHE_GCM 组合

题目二解析 (SSH)

【正确答案】

最终选定的加密算法是：aes256-ctr。

【解析过程】

根据 SSH 协议规范：

• RFC 4253 Section 7.1 规定：”The chosen encryption algorithm to each direction MUST be the first algorithm on the client’s name-list that is also on the server’s name-list.”
• GM/T 0129-2023 第12页 8.5.1 规定：”双方发送支持的算法名称列表。名称列表中的第一个为首选算法。双方在列表中选择第一个与对方达成一致的算法作为密钥协商算法。”

即：从客户端的算法列表中从左到右（优先级由高到低）逐个查找，选择第一个在服务端算法列表中也存在的算法。

逐项检查：

| 序号 | 客户端算法 | 服务端是否支持 | 结果 | | — | — | — | — | | 1 | [email protected] | ❌ 不支持 | 跳过 | | 2 | [email protected] | ❌ 不支持（注意：服务端支持的是 sm4-gcm） | 跳过 | | 3 | aes256-ctr | ✅ 支持（服务端列表第1位） | 匹配成功 |

详细分析：

1. 检查客户端第1个算法：[email protected]

• 服务端支持列表：{aes256-ctr, sm4-gcm, aes128-ctr, sm4-ctr, aes256-cbc}
• 匹配结果：未找到
• 状态：跳过，继续检查下一个

2. 检查客户端第2个算法：[email protected]

• 服务端支持列表：同上
• 匹配结果：未找到
• 注意：服务端支持的是 sm4-gcm（国密GCM模式），而非 [email protected]
• 状态：跳过，继续检查下一个

3. 检查客户端第3个算法：aes256-ctr

• 服务端支持列表：同上
• 匹配结果：找到，该算法位于服务端列表第1位
• 状态：匹配成功，停止查找

【结论】

最终协商选定的加密算法为 aes256-ctr。值得注意的是：

1. 虽然服务端最高优先级也是 aes256-ctr，但这只是巧合。核心决定因素是它在客户端列表中是首个能被服务端匹配的算法。
2. 客户端和服务端都支持国密算法（sm4-ctr），但由于 aes256-ctr 在客户端列表中排在前面，因此被优先选中。
3. 如果需要强制使用国密算法，客户端应将 sm4-ctr 或 sm4-gcm 放在列表首位。

【协议规范引用】

• RFC 4253 Section 7.1：规定了SSH算法协商的标准流程
• RFC 8308：SSH扩展协商机制
• GM/T 0129-2023 第12页 8.5.1：规定了算法协商的具体规则
• GM/T 0129-2023 第10-11页表4：定义了SM4系列加密算法

总结

TLCP、SSH、TLS 协商机制对比

实践建议

1. 客户端配置：将安全性高的算法放在列表前面，如 ECDHE_GCM 套件
2. 服务端配置：确保支持足够多的安全算法，避免协商降级到弱算法
3. 国密合规：在需要国密合规的场景下，优先配置 SM 系列算法套件
4. 硬件支持：确保硬件密码机支持所需的密钥交换和加密模式组合
5. 密钥管理：服务端密钥包括签名密钥对和加密密钥对，签名密钥用于身份鉴别，加密密钥对用于预主密钥协商
6. 参考TLS 1.3：新系统设计应参考TLS 1.3的安全实践，优先使用AEAD和前向安全性

参考标准

国家标准：

• GB/T 38636-2020：信息安全技术传输层密码协议(TLCP)
• GB/T 32905-2016：信息安全技术 SM3密码杂凑算法
• GB/T 32907-2016：信息安全技术 SM4分组密码算法
• GB/T 32918：信息安全技术 SM2椭圆曲线公钥密码算法

行业标准：

• GM/T 0044-2016：SM9标识密码算法
• GM/T 0129-2023：SSH密码协议规范

国际标准：

• RFC 4253：The Secure Shell (SSH) Transport Layer Protocol
• RFC 8308：Extension Negotiation in the Secure Shell (SSH) Protocol
• RFC 5246：The Transport Layer Security (TLS) Protocol Version 1.2
• RFC 8446：The Transport Layer Security (TLS) Protocol Version 1.3

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：利刃信安利刃信安利刃信安《TLCP & SSH 密码套件协商实战练习题》