1. 项目概述为什么我们需要一个国密测试工具最近在做一个金融相关的项目对接方明确要求通信协议必须支持国密算法。这让我和团队一下子有点懵虽然知道国密SM2/SM3/SM4是趋势但真到动手开发和联调测试时才发现市面上现成的、趁手的测试工具太少了。用 OpenSSL 吧命令复杂对国密支持得也不够“原生”自己写脚本模拟吧费时费力还容易出错联调时两边扯皮是常事。正是在这种背景下我决定动手搞一个GMProxy。简单来说GMProxy 是一个专为国密GM/T算法通信测试而设计的代理工具。它的核心功能是作为一个“中间人”透明地代理你的客户端和服务端之间的 TLS/SSL 连接但强制使用国密套件进行加密和解密。这样一来你无需修改客户端和服务端的任何代码就能直观地验证你的服务是否正确地支持了国密握手过程是否符合规范证书链校验是否通过传输的数据是否真的被国密算法加密了它非常适合以下几类人正在开发或维护需要支持国密标准应用的开发者、进行国密合规性测试的安全工程师、以及任何需要快速验证国密通信环境是否就绪的运维人员。有了它国密测试从一件令人头疼的“黑盒”猜谜变成了可以清晰观测和验证的“白盒”操作。2. 核心设计思路GMProxy 如何扮演“中间人”2.1 核心需求解析在设计 GMProxy 之前我们首先要明确在国密测试中会遇到哪些痛点环境验证困难服务端配置了国密证书和套件但客户端连接时如何确认握手一定走了国密而不是兼容的 RSA 套件日志往往不够直观。问题定位模糊握手失败时错误信息通常是“握手失败”或“协议版本不支持”难以 pinpoint 到底是证书问题、套件问题还是算法实现问题。测试成本高昂需要专门编写一个支持国密的客户端进行测试或者依赖特定的硬件设备或商业软件不够灵活和通用。流量观察缺失我们不仅想知道连接是否成功还想在测试阶段观察加密前的明文流量当然这必须在安全、可控的测试环境进行以便调试业务逻辑。基于这些痛点GMProxy 的核心设计目标就很清晰了透明代理、强制国密、详细日志、流量可视。2.2 技术方案选型为什么是正向代理而非反向实现这样一个“中间人”通常有两种思路反向代理和正向代理。反向代理部署在服务端前端所有请求先到达它再由它转发给后端服务。这需要改变网络拓扑通常用于生产环境负载均衡或入口网关。正向代理部署在客户端侧客户端主动配置代理地址。代理代表客户端去连接服务端。这对测试环境更友好无需改动服务端配置。GMProxy 选择了正向代理模式。理由很简单测试的侵入性要降到最低。在测试阶段我们通常只需要在开发机或测试客户端上配置一下代理设置比如设置https_proxy环境变量就能将指定应用的流量导向 GMProxy而不需要去改动服务端的部署。这提供了极大的灵活性。在具体实现上GMProxy 的核心是一个支持国密算法的 TLS 代理服务器。它需要同时建立两个 TLS 连接入向连接与客户端连接。GMProxy 在这里扮演“服务端”角色使用自生成的国密证书或指定的国密证书与客户端完成国密 TLS 握手。出向连接与服务端连接。GMProxy 在这里扮演“客户端”角色它使用国密套件去连接真实的后端服务。如果后端服务支持国密那么两个连接都能成功GMProxy 就在中间进行明文数据的转发和记录。如果后端不支持国密那么出向连接就会失败GMProxy 会给出明确的错误日志从而立刻验证服务端的国密支持情况。注意由于 GMProxy 需要解密客户端流量因此客户端必须信任 GMProxy 使用的证书。通常的做法是将 GMProxy 自签的国密根证书导入到客户端的信任库中。这仅适用于测试环境切勿将测试证书用于生产或信任不明确的外部服务。3. 核心细节解析与实操要点3.1 国密算法套件与 TLS 协议国密在 TLS 中的应用主要体现在密码套件上。一个国密 TLS 套件定义了四种算法密钥交换算法如ECDHE-SM2用于协商预备主密钥。身份认证算法如SM2用于服务端有时也包括客户端身份验证对应证书中的公钥算法。对称加密算法如SM4用于加密传输的应用数据。消息认证码算法如SM3用于生成消息摘要保证数据完整性。一个典型的国密套件标识符可能是ECC-SM2-WITH-SM4-SM3或TLS_SM4_GCM_SM3取决于具体实现和协议版本。GMProxy 的核心任务之一就是在与客户端和服务端握手时优先且强制地协商使用这些国密套件。在实现层面这意味着我们需要依赖支持国密的密码库。目前GMSSL和BabaSSL是两个比较成熟的选择。GMSSL 是国密算法的参考实现而 BabaSSL源自 OpenSSL则对国密有较好的支持并且兼容性更广。GMProxy 的实现需要基于这些库的 API 来构建 TLS 上下文设置密码套件列表并加载 SM2 格式的证书和私钥。3.2 证书体系双证书与单证书国密标准中定义了“签名证书”和“加密证书”双证书体系但在实际的 TLS 通信中目前更普遍使用的是单证书方案即一张证书同时包含用于签名的公钥和用于密钥交换的公钥虽然从密码学原理上是两个密钥对。GMProxy 需要能够处理这两种情况。对于测试最简单的方式是使用自签名国密证书。生成命令大致如下以 GMSSL 为例# 生成 SM2 私钥 gmssl ecparam -genkey -name sm2p256v1 -out sm2.key # 生成自签名证书 gmssl req -new -x509 -key sm2.key -out sm2.crt -days 365 -subj /CCN/STBeijing/LBeijing/OTest/CNgmproxy.test.comGMProxy 在启动时需要加载这个sm2.key和sm2.crt用于与客户端建立入向 TLS 连接。同时在连接服务端时它也需要一个信任库CA 证书包来验证服务端证书的有效性。如果测试环境使用的是自签证书也需要将服务端的 CA 证书导入到这个信任库中。3.3 代理协议与流量拦截GMProxy 需要支持通用的代理协议最基础的就是HTTP CONNECT隧道。当客户端如 curl、浏览器或 SDK配置了 HTTP 代理并发起 HTTPS 请求时会先向代理服务器GMProxy发送一个CONNECT target-host:443 HTTP/1.1的请求。GMProxy 收到后会先与target-host建立出向的国密 TLS 连接成功后再向客户端返回200 Connection Established。此后客户端才开始与 GMProxy 进行入向的 TLS 握手后续所有数据都被 GMProxy 透明转发。除了 HTTP 代理更底层和通用的方式是透明代理或端口转发。GMProxy 可以监听某个本地端口然后通过iptables或路由规则将特定目标地址的流量重定向到这个端口。这种方式可以对任何不支持配置代理的 TCP 客户端生效但设置相对复杂。在实现流量记录时GMProxy 可以在两个 TLS 连接都建立成功后在内存中解密数据并将其以明文格式如十六进制或文本输出到日志文件或控制台同时附上时间戳、连接标识等信息便于分析。4. 实操过程从零构建与运行 GMProxy4.1 环境准备与依赖安装假设我们选择用 Go 语言来实现 GMProxy因为 Go 的并发模型非常适合编写高性能的网络代理并且有成熟的crypto/tls包。但标准库的crypto/tls不支持国密因此我们需要一个支持国密的 TLS 库。这里我们选择Tongsuo铜锁原 BabaSSL的 Go 语言绑定。Tongsuo 是阿里云开源的、兼容 OpenSSL 且支持国密的密码库。首先安装 Tongsuo 库本身# 以 Ubuntu 为例 git clone https://github.com/Tongsuo-Project/Tongsuo cd Tongsuo ./config --prefix/usr/local/tongsuo enable-ntls enable-sm2 enable-sm4 enable-sm3 make -j$(nproc) sudo make install然后我们需要一个 Go 的 TLS 包装库例如github.com/emmansun/gmsm。这个库提供了基于 GMSSL/Tongsuo 的国密算法和 TLS 实现。go get github.com/emmansun/gmsm4.2 GMProxy 核心代码结构解析一个最小化的 GMProxy 核心逻辑包含以下几个部分监听器监听一个 TCP 端口接受客户端的代理连接。握手协商器对于每个客户端连接解析其初始请求如 CONNECT 方法获取目标地址。TLS 前端与客户端进行 TLS 握手强制使用国密套件使用我们自备的 SM2 证书。TLS 后端与目标服务器建立新的 TCP 连接并基于国密套件发起 TLS 握手。数据泵当两条 TLS 连接都建立成功后启动两个 goroutine在前后端之间双向转发数据。在此处可以插入钩子函数来记录或修改流量。关键代码片段示意高度简化聚焦逻辑package main import ( crypto/tls fmt io net net/http github.com/emmansun/gmsm/gmtls github.com/emmansun/gmsm/x509 ) func main() { // 1. 加载国密证书和私钥用于代理服务器自身身份 cert, err : gmtls.LoadX509KeyPair(sm2.crt, sm2.key) if err ! nil { panic(err) } // 2. 创建支持国密的 TLS 配置 tlsConfig : gmtls.Config{ Certificates: []gmtls.Certificate{cert}, CipherSuites: []uint16{ gmtls.TLS_ECC_SM2_WITH_SM4_SM3, // 强制使用国密套件 }, MinVersion: gmtls.VersionTLS12, // 国密通常基于 TLS 1.2/1.3 } // 3. 启动代理服务器 listener, _ : net.Listen(tcp, :8443) for { clientConn, _ : listener.Accept() go handleClient(clientConn, tlsConfig) } } func handleClient(clientConn net.Conn, tlsConfig *gmtls.Config) { defer clientConn.Close() // 4. 读取客户端CONNECT请求获取目标地址 // ... 解析HTTP CONNECT请求 ... // 5. 与客户端进行国密TLS握手 (GMProxy作为服务端) tlsConn : gmtls.Server(clientConn, tlsConfig) err : tlsConn.Handshake() if err ! nil { log.Printf(客户端握手失败: %v, err); return } // 6. 与目标服务器建立TCP连接 targetConn, err : net.Dial(tcp, targetAddr) if err ! nil { log.Printf(连接目标失败: %v, err); return } defer targetConn.Close() // 7. 与目标服务器进行国密TLS握手 (GMProxy作为客户端) // 注意这里需要加载信任的CA证书来验证服务器 clientTLSConfig : gmtls.Config{ RootCAs: loadTrustedCAs(), // 加载信任的CA证书池 CipherSuites: []uint16{gmtls.TLS_ECC_SM2_WITH_SM4_SM3}, } targetTLSConn : gmtls.Client(targetConn, clientTLSConfig) err targetTLSConn.Handshake() if err ! nil { log.Printf(服务端握手失败: %v, err); return } // 8. 双向转发数据 go io.Copy(targetTLSConn, tlsConn) io.Copy(tlsConn, targetTLSConn) }4.3 编译与运行测试将上述逻辑完善错误处理、日志、流量记录等后编译并运行go build -o gmproxy main.go ./gmproxy -cert sm2.crt -key sm2.key -listen :8443 -cafile trust_ca.pem现在GMProxy 就在本地的 8443 端口运行了。我们可以用 curl 命令来测试# 配置代理并使用它访问一个支持国密的测试服务 export https_proxyhttp://127.0.0.1:8443 curl -v https://sm2-test-server.com/api/data观察 GMProxy 的控制台输出你应该能看到详细的日志例如[INFO] 新客户端连接来自: 127.0.0.1:56789 [INFO] 客户端 TLS 握手成功套件: TLS_ECC_SM2_WITH_SM4_SM3 [INFO] 正在连接目标: sm2-test-server.com:443 [INFO] 服务端 TLS 握手成功套件: TLS_ECC_SM2_WITH_SM4_SM3 [INFO] 隧道建立开始转发数据...如果服务端不支持国密你会在“服务端 TLS 握手”这一步看到明确的错误比如handshake failure: no matching cipher suite found。5. 常见问题与排查技巧实录在实际使用和开发 GMProxy 的过程中我遇到了不少坑。这里总结一下希望能帮你省点时间。5.1 证书问题集锦问题1客户端报“证书不受信任”或“证书链无效”。原因客户端没有将 GMProxy 使用的自签名根证书或中间 CA 证书导入到其信任库。解决对于命令行工具如 curl使用--cacert参数指定代理的证书文件。curl --proxy-insecure可以绕过代理证书验证但不推荐。对于浏览器需要将sm2.crt导入到操作系统的根证书存储或者浏览器的证书管理器。对于 Java 应用需要将证书导入到 JVM 的cacerts信任库keytool -import -alias gmproxy -file sm2.crt -keystore $JAVA_HOME/lib/security/cacerts。心得在测试文档中第一步就应该明确告知测试人员如何安装这个测试根证书这是所有测试的前提。问题2GMProxy 连接服务端时报“远程证书无效”。原因GMProxy 不信任服务端的证书。如果服务端用的是自签国密证书你需要把它的 CA 证书也导入到 GMProxy 使用的信任库即上面代码中的trust_ca.pem文件。解决将服务端证书的 CA 文件或多个 CA合并到一个 PEM 文件中通过-cafile参数传递给 GMProxy。技巧可以使用gmssl s_client -connect server:443 -showcerts命令抓取服务端的完整证书链保存为文件。5.2 密码套件协商失败问题3客户端与 GMProxy 握手失败日志显示“no shared cipher”。原因客户端提供的密码套件列表中没有 GMProxy 强制要求的国密套件。排查检查 GMProxy 启动配置的CipherSuites列表是否正确包含了国密套件常量。用gmssl s_client -cipher或 Wireshark 抓包查看客户端实际发送的密码套件列表。某些老版本客户端或 SDK 可能默认不启用国密套件。解决确保你的测试客户端支持并启用了国密套件。对于自定义的客户端需要在 TLS 配置中显式添加国密套件。问题4GMProxy 与服务端握手失败同样报“no shared cipher”。原因服务端没有启用或配置国密套件。排查这是 GMProxy 的核心价值所在——快速验证。这个错误明确告诉你目标服务端在当前配置下不支持国密。解决检查服务端的 TLS 配置如 Nginx 的ssl_ciphers Tomcat 的Connector配置确保包含了如ECC-SM2-WITH-SM4-SM3这样的套件并且证书是 SM2 类型的。5.3 性能与调试技巧问题5传输大文件时速度慢内存占用高。原因简单的io.Copy在流量记录时如果将所有解密数据都缓冲到内存或进行复杂的日志处理会导致性能瓶颈。优化流量记录采用异步、非阻塞的方式例如将日志写入 channel由单独的 worker 协程写入文件。对于纯转发模式使用io.CopyBuffer并设置一个固定大小的缓冲区如 32KB避免大量内存分配。可以考虑提供“静默模式”或“仅记录元数据如套件、证书信息模式”来提升纯转发性能。问题6如何调试复杂的双向认证mTLS场景场景服务端要求客户端也提供国密证书。GMProxy 配置GMProxy 在与服务端连接时出向连接也需要加载客户端证书和私钥。这需要在clientTLSConfig中设置Certificates。技巧GMProxy 可以配置两套证书一套用于对客户端认证入向一套用于对服务端认证出向。通过命令行参数分别指定这两套证书路径可以灵活应对各种测试场景。问题7如何确认流量确实被国密加密了终极验证使用 Wireshark 抓包。在抓取的 TLS 握手包中查看 “Server Hello” 消息里的 “Cipher Suite” 字段。如果显示的值是0xE013或类似的对应TLS_ECC_SM2_WITH_SM4_SM3那就铁证如山了。同时后续的 “Application Data” 包应该是加密的乱码而如果你用 RSA 套件抓包某些工具可能能解密如果有 RSA 私钥但国密套件则无法解密这间接证明了其强度。6. 功能扩展与应用场景深化一个基础的 GMProxy 已经能解决大部分验证问题。但在实际项目中我们往往需要更多功能。6.1 场景一自动化测试集成在 CI/CD 流水线中我们需要自动验证每次构建的服务镜像是否支持国密。可以将 GMProxy 封装成一个测试容器。编写一个测试脚本使用配置了 GMProxy 的 HTTP 客户端如 Python 的requests库去访问待测服务。脚本通过 GMProxy 的日志或返回状态判断握手是否成功。将 GMProxy 和测试脚本打包成 Docker 镜像在流水线中启动待测服务后运行该测试容器。如果测试失败例如连接超时或握手失败CI 任务标记为失败。这样国密支持就成了一道自动化的质量关卡。6.2 场景二国密合规性审计对于安全审计人员GMProxy 可以增强为一个审计工具。证书信息详细输出不仅记录连接成功与否还详细解析并输出服务端证书的所有字段颁发者、使用者、有效期、密钥算法、签名算法等并检查是否符合国密规范如密钥长度、证书扩展项。弱密码套件检测虽然强制国密但可以记录服务端还支持哪些其他套件并警告是否存在已过时或不安全的套件如 TLS 1.0, RC4 等。生成测试报告将一次对多个目标端口的扫描结果生成结构化的报告JSON/HTML列出合规项、不合规项及证据。6.3 场景三协议分析与故障复现有时线上问题难以在测试环境复现。GMProxy 可以记录完整的、加密前的双向通信流量俗称“抓包”。在测试环境用 GMProxy 代理一个正常工作的客户端录制一次成功的请求-响应交互保存为会话文件包括 TLS 主密钥如果库支持导出的话。当线上出现问题时在同样的测试环境用 GMProxy 重放这个会话文件发送完全相同的明文数据。对比重放的结果与线上现象可以快速判断问题是出在网络、证书、服务端逻辑还是客户端数据本身。这个“录制与回放”功能对于调试复杂的国密交互协议非常有用。6.4 性能压测与基线建立在项目上线前我们需要知道支持国密后对服务性能的影响。GMProxy 可以作为一个压力测试的流量入口。统计连接指标GMProxy 可以统计每秒成功建立的国密 TLS 连接数、握手平均耗时、连接存活时间等。资源消耗监控代理本身可以汇报 CPU 和内存使用情况由于加解密是 CPU 密集型操作这些数据可以帮助评估服务端在国密场景下的资源需求。对比测试用同样的 GMProxy分别配置为国密套件和普通的 RSA 套件对同一个服务端进行压测就能直观地得到性能差异数据为容量规划提供依据。开发 GMProxy 的过程本身就是一个深入理解国密 TLS 协议的过程。它从一个简单的测试需求出发逐渐演变成一个多功能的国密通信诊断平台。工具的价值不在于它本身有多复杂而在于它能否精准地解决实际工作中那些繁琐、模糊却又至关重要的验证环节。把这个工具做稳定、做易用你会发现团队里关于国密通信的“扯皮”会少很多大家的信心也会更足。毕竟能看见的东西总是比猜测的要靠谱。