ConnProof

TLS：握手在做什么，证书为什么值得较真 ​

TLS 在 TCP 连接之上建立加密信道。它的握手阶段是连接问题的高发地带——不是因为协议脆弱，而是因为这个阶段同时承载了三件敏感的事：亮明身份（SNI）、验证身份（证书）、协商密码。每一件都可能被干预或配置错。

握手流程与两个关键时刻 ​

简化后的流程：客户端发 ClientHello（支持的版本、加密套件、SNI）→ 服务端回 ServerHello 与证书链 → 双方完成密钥交换 → 加密信道就绪。排查视角下有两个关键时刻：

  1. ClientHello 发出的瞬间：SNI（你要访问的域名）在这里明文可见。具备深度包检测能力的设备在这一刻就能决定放行、丢弃或重置——这是"TLS 握手超时"和"握手期间 EOF"最常见的发生点；
  2. 证书送达的瞬间：证书链较长时 ServerHello 需要分片，链路 MTU 异常会让分片丢失，握手永远等不齐——这是超时的另一个隐蔽成因。

证书验证的两道关 ​

客户端对证书做两道独立检查，对应两个不同的错误码：

  • 信任链：证书是否由系统信任的机构逐级签发、是否在有效期内。失败 → TLS-001 certificate verify failed；
  • 主机名匹配：证书 SAN 列表是否包含你访问的主机名。规则严格——*.example.com 只覆盖一级子域、裸域要单独列、IP 要以 IP 形式列。失败 → TLS-004 hostname mismatch。

系统时间是信任链检查的隐藏依赖：时钟偏差会让完全正常的证书被判"未生效"或"已过期"——这是全体 TLS 报错时第一个该查的东西。

为什么不能"跳过验证" ​

“跳过证书验证"的选项能让连接立刻成功，诱惑很大。但要明白它交换掉的是什么：验证是加密的意义所在——不验证对方身份的加密信道，对主动的中间人是敞开的，你以为的密文对拦截者是明文。正确的姿势是把验证失败当作诊断信号：ConnProof 的 --insecure-test 就是为此设计——它继续握手只为读取问题证书的细节作为证据，输出永远带着"不代表连接安全"的声明，且绝不把这种连接标记为安全。

与错误码的对应 ​

一分钟自查 ​

connproof tls 目标域名 --port 443

报告会给出协议版本、加密套件、SNI、证书有效期与主机名匹配的完整证据链。