gt-checksum v4.0.0 新功能解读系列文章（4）：SSL 加密连接——数据校验传输安全再升级
、功能简介
v4.0.0 为 gt-checksum 和 repairDB 同时新增了 SSL/TLS 加密连接支持。通过 8 个新增配置参数，源端和目标端可以独立配置各自的 SSL 证书和加密模式。
参数说明
gt-checksum 参数（源端 + 目标端）：
| 参数名 | 可选值 | 默认值 | 说明 |
|---|---|---|---|
srcSslCa | 文件路径 | 空 | 源端 CA 证书文件路径 |
srcSslCert | 文件路径 | 空 | 源端客户端证书文件路径 |
srcSslKey | 文件路径 | 空 | 源端客户端密钥文件路径 |
srcSslMode | 见下表 | PREFERRED | 源端 SSL 模式 |
dstSslCa | 文件路径 | 空 | 目标端 CA 证书文件路径 |
dstSslCert | 文件路径 | 空 | 目标端客户端证书文件路径 |
dstSslKey | 文件路径 | 空 | 目标端客户端密钥文件路径 |
dstSslMode | 见下表 | PREFERRED | 目标端 SSL 模式 |
repairDB 参数（仅目标端）：
| 参数名 | 说明 |
|---|---|
dstSslCa | 目标端 CA 证书文件路径 |
dstSslCert | 目标端客户端证书文件路径 |
dstSslKey | 目标端客户端密钥文件路径 |
dstSslMode | 目标端 SSL 模式 |
为什么 repairDB 只有目标端参数？repairDB 是修复工具，只连接目标端数据库执行修复 SQL，不需要源端连接，因此只需配置目标端 SSL 参数。
SSL 模式说明
| 模式 | 说明 | 需要 CA 证书？ |
|---|---|---|
DISABLED | 禁用 SSL，不加密连接 | 否 |
PREFERRED | 优先使用 SSL，服务端不支持时回退到非加密连接 | 否 |
REQUIRED | 必须使用 SSL 加密，但不验证服务端证书 | 否 |
VERIFY_CA | 验证服务端 CA 证书链 | 是 |
VERIFY_IDENTITY | 验证 CA 证书链和服务端身份（主机名） | 是 |
使用方式非常简单，在配置文件gc.conf中添加几行即可：
; 最小配置：仅要求加密，不验证证书 |
srcSslMode=REQUIRED |
dstSslMode=REQUIRED |
二、功能作用及使用场景深入解读
2.1 为什么需要 SSL 加密连接？
在数据校验和修复场景中，gt-checksum 需要从源端和目标端大量读取数据进行比对。如果连接未加密，数据在传输过程中存在被窃听或篡改的风险。
场景一：跨机房/跨云校验
源端和目标端分别部署在不同云平台，校验流量经过公网传输。如果没有 SSL 加密，数据包可以被中间节点抓取和分析。
场景二：安全合规要求
金融、医疗、政务等行业对数据传输有严格的加密要求。数据库审计系统可能要求所有数据库连接必须使用加密通道，即使是只读查询也不例外。
场景三：共享网络环境
在 Kubernetes 集群或共享 VPC 中，不同租户的流量可能共享物理网络。虽然有网络隔离，但深度防御（Defense in Depth）原则要求在传输层也做加密保护。
场景四：修复 SQL 中的敏感数据
repairDB 执行的修复 SQL 可能包含用户个人信息、交易记录等敏感数据。这些 SQL 文本通过明文连接传输时，等同于将敏感数据直接暴露在网络上。
2.2 五种 SSL 模式：从"只加密"到"全面验证"
gt-checksum 提供了五种 SSL 模式，覆盖从最低安全要求到最高安全级别的全部场景：
DISABLED——明确禁用
srcSslMode=DISABLED |
显式禁用 SSL。适用于已经在网络层面做了加密（如 VPN、专线），或者在完全可信的内网环境中使用。
PREFERRED——自适应模式（默认值）
srcSslMode=PREFERRED |
优先尝试 SSL 连接，如果服务端不支持则回退到非加密连接。这是设置了其他 SSL 参数但未显式指定mode时的默认值。适用于过渡期场景——源端和目标端可能部分启用了 SSL。
REQUIRED——强制加密
srcSslMode=REQUIRED |
强制使用 SSL 加密，但不验证服务端证书。这意味着传输数据是加密的，但客户端不会检查服务端证书是否由可信 CA 签发。适用于内部环境，需要加密但不担心中间人攻击的场景。
VERIFY_CA——验证证书链
srcSslCa=/path/to/ca.pem |
srcSslMode=VERIFY_CA |
验证服务端证书是否由指定的 CA 签发。需要提供 CA 证书文件（srcSslCa或dstSslCa）。这是生产环境推荐的最低安全级别。
VERIFY_IDENTITY——全面验证
srcSslCa=/path/to/ca.pem |
srcSslMode=VERIFY_IDENTITY |
在验证 CA 证书链的基础上，还验证服务端身份（主机名匹配）。这是最高安全级别，能有效防御中间人攻击。使用此模式时，服务端证书的 CN 或 SAN 必须与 DSN 中的主机名一致。
2.3 客户端证书认证
除了验证服务端身份，gt-checksum 还支持双向 TLS 认证（mTLS）——客户端也向服务端出示证书。适用于数据库配置了REQUIRE X509或REQUIRE SUBJECT的场景。
; 源端 mTLS 配置 |
srcSslCa=/path/to/ca.pem |
srcSslCert=/path/to/client-cert.pem |
srcSslKey=/path/to/client-key.pem |
srcSslMode=VERIFY_CA |
同时验证所有证书文件必须存在且可读，否则启动时报错退出，避免运行时才发现证书缺失。
2.4 源端和目标端独立配置
gt-checksum 的一个关键设计是源端和目标端完全独立配置SSL 参数。这意味着：
- 源端使用
VERIFY_CA，目标端可以使用REQUIRED - 源端和目标端可以使用不同的 CA 证书
- 源端启用 SSL，目标端可以不启用
; 源端：严格的证书验证 |
srcSslCa=/certs/source-ca.pem |
srcSslCert=/certs/source-client.pem |
srcSslKey=/certs/source-client-key.pem |
srcSslMode=VERIFY_CA |
; 目标端：仅加密 |
dstSslMode=REQUIRED |
这种设计源于真实生产环境的需求——源端可能是外部公司提供的数据库（使用他们的 CA），目标端是内部数据库（使用内部 CA 或暂未配置证书）。
2.5 SSL 参数激活条件
SSL 配置并非无条件生效。gt-checksum 设计了明确的激活条件：
- 至少一个 SSL 参数非空：
srcSslCa、srcSslCert、srcSslKey、srcSslMode中至少有一个不为空，才激活源端 SSL 配置。目标端同理。 - 驱动必须为 MySQL：Oracle 数据源不支持此配置。代码中通过
SrcDrive == "mysql"和DestDrive == "mysql"进行判断。 - mode 未设置时默认 PREFERRED：如果设置了其他 SSL 参数（如
srcSslCa）但未设置srcSslMode，默认使用PREFERRED模式。 - 向后完全兼容：未配置任何 SSL 参数时，行为与 v3.x 完全一致，DSN 不会被修改。
三、功能使用演示
3.1 最小配置：仅要求加密
不关心证书验证，只希望数据传输加密：
srcDSN=user:ENC[...]@tcp(10.0.0.1:3306)/db1 |
dstDSN=user:ENC[...]@tcp(10.0.0.2:3306)/db1 |
; 两端都要求 SSL 加密，不验证证书 |
srcSslMode=REQUIRED |
dstSslMode=REQUIRED |
启动后，gt-checksum 会在日志中输出 TLS 配置已应用（DSN 中的密码会被脱敏）：
$ gt-checksum -c gc.conf |
Initializing gt-checksum |
Reading configuration files |
Source SSL: mode=REQUIRED (encryption only, no certificate verification) |
Destination SSL: mode=REQUIRED (encryption only, no certificate verification) |
... |
3.2 完整配置：CA 证书验证
生产环境推荐使用VERIFY_CA模式，验证服务端证书：
srcDSN=user:ENC[...]@tcp(10.0.0.1:3306)/db1 |
dstDSN=user:ENC[...]@tcp(10.0.0.2:3306)/db1 |
; 源端 SSL：完整证书验证 |
srcSslCa=/etc/ssl/certs/source-ca.pem |
srcSslCert=/etc/ssl/certs/source-client.pem |
srcSslKey=/etc/ssl/private/source-client-key.pem |
srcSslMode=VERIFY_CA |
; 目标端 SSL：完整证书验证 |
dstSslCa=/etc/ssl/certs/dest-ca.pem |
dstSslCert=/etc/ssl/certs/dest-client.pem |
dstSslKey=/etc/ssl/private/dest-client-key.pem |
dstSslMode=VERIFY_CA |
3.3 混合配置：源端严格、目标端宽松
源端是外部数据库需要严格验证，目标端是内部数据库仅需加密：
srcDSN=user:ENC[...]@tcp(ext-mysql.example.com:3306)/db1 |
dstDSN=user:ENC[...]@tcp(10.0.0.2:3306)/db1 |
; 源端：验证证书和主机名 |
srcSslCa=/etc/ssl/certs/external-ca.pem |
srcSslMode=VERIFY_IDENTITY |
; 目标端：仅加密 |
dstSslMode=REQUIRED |
3.4 repairDB 配置
repairDB 使用相同的配置文件，只需配置dstSsl*系列参数：
dstDSN=user:ENC[...]@tcp(10.0.0.2:3306)/db1 |
fixFileDir=./fixsql |
; 目标端 SSL |
dstSslCa=/etc/ssl/certs/dest-ca.pem |
dstSslCert=/etc/ssl/certs/dest-client.pem |
dstSslKey=/etc/ssl/private/dest-client-key.pem |
dstSslMode=VERIFY_CA |
$ repairDB -c gc.conf |
[REPAIR] Destination SSL: mode=VERIFY_CA (CA certificate verification enabled) |
[REPAIR] Processing: fix-orders-001.sql ... OK |
... |
3.5 启动报错示例
证书文件不存在时，gt-checksum 会在启动阶段立即报错退出：
$ gt-checksum -c gc.conf |
gt-checksum: Source SSL configuration error: CA certificate file not found: /path/to/nonexistent-ca.pem |
客户端证书和密钥未配对时：
$ gt-checksum -c gc.conf |
gt-checksum: Source SSL configuration error: both sslCert and sslKey must be provided together (got cert="/path/to/client.pem", key="") |
四、最佳实践及使用约束
4.1 最佳实践
1. 生产环境建议使用VERIFY_CA或VERIFY_IDENTITY
REQUIRED模式虽然加密了传输数据，但不验证服务端证书，存在中间人攻击风险。生产环境建议至少使用VERIFY_CA：
srcSslCa=/etc/ssl/certs/ca.pem |
srcSslMode=VERIFY_CA |
dstSslCa=/etc/ssl/certs/ca.pem |
dstSslMode=VERIFY_CA |
2. 配合 DSN 密文保护使用
SSL 加密了传输通道，但配置文件中的 DSN 密码仍然需要保护。建议配合ENC[...]密文和gt-dsn-crypt工具一起使用：
srcDSN=user:ENC[...]@tcp(10.0.0.1:3306)/db1 |
dstDSN=user:ENC[...]@tcp(10.0.0.2:3306)/db1 |
srcSslMode=VERIFY_CA |
dstSslMode=VERIFY_CA |
3. 内网环境可使用REQUIRED作为最低要求
如果校验任务完全在可信内网中运行，且服务端证书管理尚未完善，REQUIRED模式可以作为过渡方案——至少保证传输数据不被明文窃取：
srcSslMode=REQUIRED |
dstSslMode=REQUIRED |
4. 证书文件权限管理
CA 证书和客户端密钥文件应设置适当的文件权限，避免未授权访问：
# 密钥文件仅 owner 可读 |
chmod 600 /etc/ssl/private/client-key.pem |
# CA 证书和客户端证书可被工具进程读取 |
chmod 644 /etc/ssl/certs/ca.pem |
chmod 644 /etc/ssl/certs/client.pem |
6. 测试环境先验证再上线
首次配置 SSL 时，建议先在测试环境验证：
# 1. 确认证书文件可读 |
ls -la /path/to/ca.pem /path/to/client-cert.pem /path/to/client-key.pem |
# 2. 使用 openssl 验证证书有效性 |
openssl x509 -in /path/to/ca.pem -text -noout |
openssl verify -CAfile /path/to/ca.pem /path/to/client-cert.pem |
# 3. 启动 gt-checksum 观察日志 |
gt-checksum -c gc.conf |
4.2 使用约束
1. 仅对 MySQL-family 数据源生效
SSL 参数仅对 MySQL 数据源生效（包括 MySQL、GreatSQL、Percona Server、MariaDB）。Oracle 数据源不支持此配置，设置 SSL 参数会被静默忽略。这是由于 Oracle 使用完全不同的 SSL 机制（Oracle Net / TCPS），不在本次实现范围内。
2. VERIFY_CA / VERIFY_IDENTITY 必须提供 CA 证书
使用VERIFY_CA或VERIFY_IDENTITY模式时，必须提供对应端的 CA 证书文件（srcSslCa或dstSslCa），否则启动时报错。这是强制要求——没有 CA 证书就无法验证服务端证书链。
3. 客户端证书必须配对
使用客户端证书认证时，sslCert和sslKey必须同时配置。只提供其中一个会在启动时报错。这是 TLS 协议的基本要求——证书和私钥必须匹配才能完成握手。
4. 所有证书文件必须存在且可读
gt-checksum 在配置解析阶段就会验证所有证书文件的存在性和可读性。文件不存在或无读取权限时，程序立即报错退出，不会进入校验流程。这是一个 fail-fast 设计，避免运行到一半才发现证书问题。
5. SslMode 不区分大小写
配置文件中的srcSslMode和dstSslMode值不区分大小写。verify_ca、VERIFY_CA、Verify_Ca都是合法的。代码中会统一转为大写后进行匹配。
6. DSN 中已有的tls=参数会被替换
如果 DSN 连接串中已经手动指定了tls=参数，gt-checksum 会用 SSL 配置生成的值替换它，而非追加。这避免了 DSN 中出现两个tls=参数导致驱动行为不确定的问题。
五、总结
gt-checksum v4.0.0 的 SSL 加密连接支持，让数据校验和修复过程中的传输安全不再是空白。通过五种 SSL 模式覆盖从"仅加密"到"全面验证"的全部安全需求，源端和目标端独立配置的设计则适应了异构环境下的真实生产场景。
对生产环境的安全建议：
- 最低要求：
REQUIRED模式，保证传输加密 - 推荐配置：
VERIFY_CA模式，验证服务端证书链 - 最高安全：
VERIFY_IDENTITY+ 客户端证书，双向认证 + 主机名验证 - 完整方案：SSL 加密传输 +
ENC[...]密文保护密码 + 日志自动脱敏
一句话总结：srcSslMode=VERIFY_CA，让校验数据不再裸奔。