ARTICLE DETAIL

建站实战干货

来自一线的建站与推广经验沉淀,每一条都经过真实交付验证。

写在前面:这套测试到底在测什么

2026/10/1 10:26:35 拓冰建站 浏览量
写在前面:这套测试到底在测什么 缘起电力监控系统里104 规约IEC 60870-5-104过去是明文跑的谁都能在链路上看也能往里塞东西。IEC 62351-3 就是来解决这个问题的它把 TLS 套在 TCP 之上让 104 的报文有了加密和双向认证。但支持 TLS这四个字太笼统了。一个设备说自己支持 62351-3到底是真按规矩做的还是只是能握手成功比如它允许不允许 TLS 1.0 接进来收到一张过期的客户端证书它是报警还是装没看见对方一直不响应重协商它会不会傻等下去这些问题IEC 62351-3 本身没有逐条给出负面场景的预期行为于是就有了 IEC TS 62351-100-3。它是 62351-3 的一致性测试用例集其中第 6.3 节专门管异常情况下设备该怎么做也就是 resiliency test。我们这轮要做的事就是把这 39 条测例在一台真实设备上跑一遍。被测对象和测试拓扑被测设备DUT是服务端角色也就是变电站里的装置或者主站前置机跑 104 服务监听安全端口 19998。测试设备是客户端角色由我们自己控制可以任意构造握手参数和证书。拓扑很朴素就两台一台 DUT一台测试机。中间隔着交换机或者直连都行。真正的工作量不在网络而在客户端能造出多刁钻的输入。证书体系整个测试的基石是一套自建的 PKI。根 CA 自己签服务器证书和正常客户端证书都由它签发。光有正常证书不够绝大部分测例要的是一张有问题但看起来很正常的证书所以我们准备了这么一批证书怎么造的用来测什么client正常签发基线证明环境本身是通的big塞 200 个 subjectAltName把体积撑大证书超尺寸other_client另一个 CAother_ca签发签发 CA 没装client_diff同一个 CA换个 CN个体证书不在白名单expired有效期设成 2020-01-01 到 2020-01-02证书过期revoked签发后写进 CRL证书被吊销min1024RSA 1024 位密钥长度踩在 legacy 下限shortRSA 512 位密钥长度不够md5用 MD5 签名签名算法不被接受tampered把 PEM 里的一个字节翻转签名对不上生成脚本是纯 Python用 cryptography 库直接写 X.509没依赖 openssl 命令行。这样跨平台稳也不用担心不同版本 openssl 的参数差异。CRL 也得准备两份一份正常的ca.crl里面有 revoked 那张证书的序列号一份故意做旧的ca_expired.crlnextUpdate 时间设在过去用来测CRL 过期。服务端该有的配置为了让测试有意义DUT 必须按 PIXIT 声明的那套参数来配。我们这边的口径是TLS 版本只开 1.21.0、1.1、1.3 全关密码套件只留 AES128-GCM-SHA256 和 AES256-GCM-SHA384强制双向认证客户端必须出示证书信任锚是ca.crt吊销检查用ca.crl最大证书尺寸声明为 4096 字节重协商间隔声明 60 秒测试时临时调到 10 秒。只要有一条对不上测出来的结果就没法往标准上套。所以每次换设备第一件事都是先核对这套参数。三种客户端工装初始握手组的测例大多数用 openssl 命令行就够了s_client换几个参数就能造出对应场景。但重协商组不行那些场景要控制第一次正常、第二次变坏的时序命令行做不到只能自己写 C 程序。我们前后攒了三类工装第一类openssl s_client。换证书、换版本、换密码套件一行命令的事。初始握手组里凡是不涉及状态变化的都用它。第二类cert_callback 切证书。客户端注册一个证书回调初始握手和第一次重协商加载正常证书等到设定的那次重协商再换成异常证书。6.3.29 之后那一批基本都套这个模板改的只是喂进去的异常证书路径。第三类BIO 过滤器。这个稍微绕一点。重协商时 TLS 记录头的版本字段是明文的我们可以挂一个自定义 BIO在写出去之前把03 03TLS 1.2改成03 01TLS 1.1这样协商出来的版本就和初始握手不一致了6.3.21 和 6.3.23 靠它。6.3.22 则反过来在读方向拦截并丢弃服务端发来的 HelloRequest让服务端等不到回应。这三类工装对应的客户端程序命名都是c6-3-XX交叉编译后丢到目标板上跑。M、PICS、PIXIT 是什么意思标准里每条测例都标了 Required取值有三种M是强制跟 62351-3 里的强制条款挂钩跑不了。PICS是有条件的只有当设备的 PICS 声明里勾了对应功能这条才适用。比如 6.3.1 要求设备支持 TLS 1.1可我们这台设备压根不支持这条对我们就是 NA不用测。系列里带 PICS 的那几篇我会说清楚条件是什么、什么情况下才需要动手。PIXIT也是有条件但取决于 PIXIT 里声明的具体参数值比如重协商间隔、CRL 检查方式、最大证书尺寸。设备声明的值不同测法会跟着变。怎么读这个系列39 条测例一条一篇按编号顺序排。每篇大致是这个路子先说这个场景在现实里意味着什么再给标准要求的预期行为然后讲我们怎么把这个场景造出来最后是怎么判定设备做对了。如果你只想看个大概读 README 里的目录表每篇都有一句话摘要。如果你要照着复现建议从 6.3.3 开始看那是第一条不依赖额外条件的 M 测例跑通了再往下。有一点得提前说明这套东西测的是设备的行为对不对不是加密强不强。TLS 本身的实现正确性不在这个标准的范围内那是 RFC 的事。所以别指望用这套用例去发现 TLS 库的漏洞它找的是设备有没有按 62351-3 的规矩办事。