数据库安全传输层启用TLS1.3与强密码套件

数据库安全传输层启用TLS 1.3并配置强密码套件，核心就是三件事：第一，把数据库的TLS版本从1.0/1.1/1.2直接升级到1.3；第二，禁用所有弱密码算法，只保留TLS_AES_256_GCM_SHA384、TLS_CHACHA20_POLY1305_SHA256这类强套件；第三，确保证书链完整、密钥长度不低于256位。做完这三步，数据库在传输过程中的数据窃听、中间人攻击、降级攻击风险基本可以降到最低。下面我把每个环节拆开来讲，从原理到配置到验证，全部讲透。

很多人觉得TLS 1.2已经够安全了，没必要折腾TLS 1.3。这个想法在2024年之后是有问题的。TLS 1.2虽然还在广泛使用，但它有几个硬伤：握手需要两个RTT（往返时延），密钥交换算法选择多但不够统一，而且历史上出现过不少针对TLS 1.2的实战攻击，比如BEAST、POODLE虽然是老漏洞，但说明协议本身的设计复杂度就是攻击面。TLS 1.3把握手压缩到1个RTT甚至0-RTT，直接砍掉了RSA密钥交换、静态DH、CBC模式加密等一堆不安全的算法，协议层面就把风险降下来了。对于数据库这种高敏感数据的传输通道，能少一个攻击面就少一个攻击面，这是原则问题。

TLS 1.3的密码套件数量比TLS 1.2少得多，这不是缺点，是优点。它只保留了五个官方套件，其中真正实用且安全的就两个：

TLS_AES_256_GCM_SHA384
TLS_CHACHA20_POLY1305_SHA256
TLS_AES_128_GCM_SHA256

第一个用AES-256-GCM加密，SHA-384做HMAC；第二个用ChaCha20-Poly1305，适合没有AES硬件加速的设备；第三个是AES-128-GCM，安全性够用但密钥长度短一些。如果你的数据库服务器有AES-NI指令集支持，优先选TLS_AES_256_GCM_SHA384。如果是ARM架构或者老旧硬件，选TLS_CHACHA20_POLY1305_SHA256。绝对不要在TLS 1.3下再去配什么AES-CBC、3DES之类的，协议层直接不支持，强行配也配不上。

MySQL从8.0开始原生支持TLS 1.3，但默认配置可能没有打开。首先检查当前版本和TLS状态：

mysql> SHOW VARIABLES LIKE '%tls_version%';
mysql> SHOW VARIABLES LIKE '%ssl%';

如果tls_version显示的是TLSv1.2或者更低，需要修改my.cnf配置文件：

[mysqld]
tls_version=TLSv1.3
ssl_cipher=TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256
ssl_cert=/etc/mysql/ssl/server-cert.pem
ssl_key=/etc/mysql/ssl/server-key.pem
ssl_ca=/etc/mysql/ssl/ca-cert.pem
require_secure_transport=ON

require_secure_transport=ON这一行很关键，它强制所有连接必须走TLS，不允许明文回退。改完之后重启MySQL服务，再用客户端连接测试：

mysql -u root -p --ssl-mode=REQUIRED --tls-version=TLSv1.3

连接成功后用status命令确认：

mysql> \s
--------------
mysql  Ver 8.0.35

SSL: Cipher in use is TLS_AES_256_GCM_SHA384

看到Cipher显示TLS_AES_256_GCM_SHA384就说明配置生效了。

PostgreSQL从12版本开始支持TLS 1.3，14版本之后支持更完善。编辑postgresql.conf：

ssl = on
ssl_cert_file = 'server.crt'
ssl_key_file = 'server.key'
ssl_ca_file = 'root.crt'
ssl_min_protocol_version = 'TLSv1.3'
ssl_ciphers = 'TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256'

注意ssl_min_protocol_version这个参数，直接设成TLSv1.3就把1.0/1.1/1.2全部禁掉了。如果你还有旧客户端需要兼容，可以设成TLSv1.2，但强烈建议尽快全部迁移到1.3。另外pg_hba.conf里也要加上对应的hostssl条目：

hostssl all all 0.0.0.0/0 scram-sha-256

这样只允许TLS加密的连接进来。

SQL Server 2022开始支持TLS 1.3，之前的版本最高到1.2。如果你用的是2022，通过SQL Server Configuration Manager操作：在SQL Server Network Configuration里找到对应实例的Protocols，右键属性，把Force Encryption设为Yes，然后在注册表里确认TLS 1.3已启用。注册表路径：

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.3\Server
Enabled = 1 (DWORD)

同时在客户端连接字符串里指定加密=true和TrustServerCertificate=false，确保验证证书链。

光开TLS 1.3不够，证书本身也得过硬。现在的行业标准是：RSA密钥至少2048位，推荐4096位；ECDSA密钥用P-256或P-384曲线；证书签名算法用SHA-256或SHA-384，绝对不要用SHA-1。证书有效期不要超过一年，最好用自动化工具续期。私钥存储必须加密，AES-256加密私钥文件是基本要求。如果你用的是自签证书，至少要保证CA根证书在所有客户端都预装了，否则每次连接都会报证书不受信任的错误。

还有一点容易忽略：证书的Subject Alternative Name（SAN）字段必须包含数据库服务器的实际域名或IP，不能只有Common Name。现代TLS实现都优先校验SAN，CN字段基本被废弃了。

配置完不能光看配置文件，必须实测。用openssl命令直接测试：

openssl s_client -connect db-server:3306 -tls1_3

如果返回握手成功并且Cipher显示TLS_AES_256_GCM_SHA384，说明没问题。如果报错或回退到TLS 1.2，说明配置有问题或者客户端不支持。另外可以用nmap扫描：

nmap --script ssl-enum-ciphers -p 3306 db-server

这个脚本会列出服务器支持的所有TLS版本和套件，一目了然。还有一个更狠的验证方法：用Wireshark抓包，看实际传输的数据包里TLS Record的Version字段是不是0x0304（TLS 1.3的标识），以及Cipher Suite是不是你配置的那几个。

第一，客户端驱动不支持TLS 1.3。比如老版本的MySQL Connector/J、旧的libpq、或者某些ORM框架内置的数据库驱动，可能最高只支持到TLS 1.2。解决办法是升级驱动到最新版，或者在应用层加一个支持TLS 1.3的代理。第二，操作系统底层OpenSSL版本太低。TLS 1.3需要OpenSSL 1.1.1以上，如果你的服务器跑的是CentOS 7自带的OpenSSL 1.0.2，那根本用不了TLS 1.3，必须升级系统或者编译新版本OpenSSL。第三，负载均衡器或中间件不透传TLS 1.3。有些数据库前面挂了ProxySQL、HAProxy或者云厂商的数据库代理，这些中间件可能只支持到TLS 1.2，需要单独升级中间件版本。第四，性能顾虑。TLS 1.3因为握手快、加密效率高，实际性能比TLS 1.2还好，尤其是1-RTT握手和0-RTT恢复，延迟更低。唯一可能的性能损耗是AES-256比AES-128计算量大一点，但在有硬件加速的情况下几乎可以忽略。

现在不管是等保2.0、PCI DSS、还是各类数据安全法规，都明确要求传输加密必须使用强加密协议。TLS 1.0和1.1在2020年之后已经被PCI DSS正式禁用，TLS 1.2虽然还在合规清单里，但越来越多的审计标准开始推荐甚至要求TLS 1.3。如果你的数据库承载的是用户隐私数据、金融数据、医疗数据，用TLS 1.3不是加分项，是必选项。从审计角度讲，你能拿出TLS 1.3的配置截图和抓包验证结果，比任何口头承诺都有说服力。

数据库传输安全这件事，说复杂也复杂，说简单也简单。核心就一句话：把TLS版本拉到1.3，密码套件锁死在AES-256-GCM或ChaCha20-Poly1305，证书用强算法、短有效期，客户端驱动和中间件全部升级到位。做完之后用openssl和抓包双重验证，确保没有回退。这不是一次性的工作，证书要定期续期，驱动要持续更新，配置要定期审计。数据库安全没有终点，只有不断加固的过程。现在就去检查你的数据库TLS版本，如果还在用1.0或1.1，今天就该动手改了。