安全攻防 - 02 标准背景：国际 TLS、RFC 8998 与中国 TLCP

这一篇回答一个经常让新手困惑的问题：

国密 SSL、TLCP、GMSSL、NTLS、TLS 1.3 国密套件、SM2 证书，到底是不是一回事？

结论先说：不是一回事。它们有关联，但不能混用。

1. 国际 TLS：普通 HTTPS 的主流基础

1.1 TLS 1.2

TLS 1.2 对应 RFC 5246，发布于 2008 年。它长期是互联网 HTTPS 的主力版本。

TLS 1.2 的特点是密码套件名字里通常包含很多信息，例如：

TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256

这个名字大概说明：

• 用 ECDHE 做临时密钥交换；
• 用 RSA 做认证；
• 用 AES-128-GCM 做对称加密；
• 用 SHA-256 做摘要/伪随机函数相关工作。

1.2 TLS 1.3

TLS 1.3 对应 RFC 8446，发布于 2018 年。它废弃了很多旧算法，握手流程也比 TLS 1.2 更现代。

TLS 1.3 的密码套件名字更短，例如：

TLS_AES_128_GCM_SHA256

为什么少了 RSA/ECDHE？因为 TLS 1.3 把“密钥交换、签名算法、对称加密”拆到不同扩展里协商，不再像 TLS 1.2 那样全塞在一个套件名里。

2. RFC 8998：TLS 1.3 里怎么用国密算法

RFC 8998 讲的是在 TLS 1.3 中使用 ShangMi/SM 算法的方式，包括：

TLS_SM4_GCM_SM3 TLS_SM4_CCM_SM3

它涉及：

• SM2：签名/认证；
• SM3：杂凑；
• SM4：对称加密；
• ECDHE over SM2 curve：密钥交换相关机制。

但是要特别注意：RFC 8998 是TLS 1.3 profile，不是 TLCP。

它也不是 IETF 标准轨文档，而是 informational RFC。RFC 8998 页面明确说明它不是 Internet Standards Track 规范，并且 SM 算法的使用不代表 IETF 推荐。

所以当对方说“国密 TLS 1.3”时，你要确认是不是 RFC 8998；当对方说“TLCP/GMSSL/NTLS”时，就不是 RFC 8998 这条线。

3. 中国 TLCP：GB/T 38636-2020

中国国家标准 GB/T 38636-2020《信息安全技术 传输层密码协议（TLCP）》 于 2020-04-28 发布，2020-11-01 实施，状态为现行。

TLCP 可以理解为一种“TLS-like”的传输层密码协议，但它不是普通 TLS 1.2，也不是 TLS 1.3。

Tencent Kona 的 README 里也解释过命名：GB/T 38636-2020 定义的名称是Transport layer cryptography protocol，在 Kona 项目里协议名叫TLCP，版本是1.1；历史上很多人也叫 GMSSL / GMSSL 1.1。

本工程配置的是：

protocol:TLCPv1.1enabled-protocols:-TLCPv1.1

所以本工程主线是TLCP v1.1 客户端接入，不是 TLS 1.3 + RFC 8998。

4. SM2、SM3、SM4 分别负责什么

国密 SSL/TLCP 里常见的算法是 SM2、SM3、SM4。

4.1 SM2

SM2 是椭圆曲线公钥密码算法系列。常见用途：

• 数字签名；
• 公钥加密；
• 密钥交换；
• 证书公钥算法。

标准入口：

• GB/T 32918.2-2016 SM2 第 2 部分：数字签名算法
• GB/T 32918.5-2017 SM2 第 5 部分：参数定义

在 TLCP 里，SM2 常用于服务端证书签名验证、ServerKeyExchange 签名验证，以及加密预主密钥等环节。

4.2 SM3

SM3 是密码杂凑算法。标准入口：GB/T 32905-2016 SM3 密码杂凑算法。

你可以把 SM3 类比为国密体系里的 SHA-256 角色：把任意长度输入压缩成固定长度摘要，用于签名、消息认证、密钥派生等场景。

本工程里一个关键配置是：

client-signature-schemes:-sm2sig_sm3

它会写入 Kona 系统属性：

com.tencent.kona.ssl.client.signatureSchemes=sm2sig_sm3

作用是让 ClientHello 告诉服务端：客户端支持 SM2 + SM3 的签名算法。

4.3 SM4

SM4 是分组密码算法。标准入口：GB/T 32907-2016 SM4 分组密码算法。

在 TLCP 里，SM4 是握手后真正加密业务数据的对称算法。常见模式：

SM4-GCM SM4-CBC

本工程默认套件：

TLCP_ECC_SM4_GCM_SM3 TLCP_ECC_SM4_CBC_SM3

5. TLCP、GMSSL、NTLS 名字怎么对齐

不同生态里名字不完全一致：

Tongsuo TLCP 使用手册 中说明，NTLS 在 Tongsuo 里指符合 GM/T 0024 SSL VPN 和 TLCP 协议的安全通信协议，并强调其特征是加密证书/私钥与签名证书/私钥分离。

所以你和服务端沟通时，不要只问：

你们是不是国密？

应该问：

你们端口跑的是 TLCP/GMSSL/NTLS，还是 TLS 1.3 + RFC 8998？ 协议版本字符串是什么？服务端密码套件名称是什么？

6. 为什么本工程选 Tencent Kona

Java 里要做 TLCP，核心问题是 JDK 默认 Provider 不够。

Tencent Kona SM Suite 的官方 README 说明它是一组 Java 安全 Provider，覆盖 SM2、SM3、SM4、TLCP/GMSSL、TLS 1.3 with RFC 8998 等能力，并拆成多个模块：

本工程没有直接依赖一个“万能国密客户端”，而是按 Java 安全体系拼装：

Security Provider → CertificateFactory / KeyStore / TrustManagerFactory → SSLContext → SSLSocketFactory → OkHttp → Forest

这样好处是：

• 和 Java 生态兼容；
• 可以明确看到哪个环节失败；
• 可以在 Web 诊断页面展示证书、Provider、握手信息；
• 业务层仍然用 Forest 发 HTTP 请求，不需要重写 multipart。

7. 标准和实现之间的关系

标准告诉你“协议应该是什么样”，实现告诉你“这门语言里怎么用”。

以本工程为例：

也就是说：标准没有直接告诉你怎么绕过 OkHttp 的枚举；实现代码必须处理这些生态边界。

8. 对接时的判断题

8.1 对方说“我们是国密双证书”

大概率是 TLCP/GMSSL/NTLS。你要继续问：

• 服务端签名证书和加密证书是否都配好了？
• 客户端是否需要双证书？
• 支持哪些套件：ECC 还是 ECDHE？
• 端口是否只跑 TLCP？

8.2 对方说“我们是 TLS 1.3 国密套件”

可能是 RFC 8998。你要继续问：

• 支持TLS_SM4_GCM_SM3还是TLS_SM4_CCM_SM3？
• 是否要求 SM2 证书？
• Java 客户端使用哪个 Provider？
• 是否支持普通浏览器访问？

8.3 对方只说“SM2 证书”

这不够。SM2 证书可以出现在不同协议里。你要问协议版本和密码套件。

8.4 对方给你.cer文件

这也不够。你要问它是：

• 根 CA？
• 中间 CA？
• 服务端签名证书？
• 服务端加密证书？
• 客户端证书？

不同证书放的位置完全不同。

9. 本篇小结

• 国际 HTTPS 主流基础是 TLS 1.2/1.3。
• RFC 8998 是 TLS 1.3 中使用国密算法的一种 profile，不等于 TLCP。
• TLCP 是 GB/T 38636-2020 定义的传输层密码协议，本工程使用TLCPv1.1。
• SM2、SM3、SM4 分别覆盖公钥、杂凑、对称加密能力。
• GMSSL、NTLS、TLCP 常在不同生态里混叫，对接时必须问清协议版本和套件。
• 本工程用 Tencent Kona 把国密算法、证书、TLCP SSLContext 接入 Java，再桥接到 OkHttp/Forest。

下一篇我们进入 TLCP 握手本身，重点看双证书和密码套件。