我上周帮一家电商公司排查安全扫描报告，支持l中发现他们的等强度密洞nginx配置里赫然列着`ECDHE-RSA-AES128-SHA`和`DHE-RSA-AES256-SHA`这类套件——都是中等强度密码套件。安全扫描工具给这个漏洞标记为“高风险”，码套但开发负责人一脸茫然：“我们明明启用了TLS1.2，支持l中怎么还有问题？等强度密洞”

问题恰恰出在“启用”变成了“兼容”。很多服务器为了照顾老客户端，码套把加密套件列表设置成“越靠前越优先，支持l中但全部可用”。等强度密洞比如那个`AES128-SHA`，码套用的支持l中是CBC模式，有padding oracle攻击风险；`DHE`套件虽然提供前向保密，等强度密洞但密钥交换参数如果没设好，码套容易受到Logjam攻击。支持l中中等强度套件就像用密码锁却配了把塑料钥匙——看着能用，等强度密洞实际一掰就断。码套

真实场景里更隐蔽。我见过某银行内部系统，运维为了兼容一台2012年的老打印机，硬是把`TLS_RSA_WITH_AES_128_CBC_SHA`留在了列表里。打印机确实能连了，但任何能截获流量的攻击者都能用已知明文攻击逐步还原会话密钥。更讽刺的是，这台打印机打印的恰好是安全审计报告。

修复方案其实不复杂：在nginx或Apache里显式禁用所有`CBC`模式套件，只保留`ECDHE_RSA_WITH_AES_128_GCM_SHA256`这类AEAD套件。但难点在于“中等强度”的定义会漂移——三年前`AES128-GCM`还算强，现在某些合规标准要求必须用`AES256-GCM`。我自己的习惯是直接参考Mozilla的ssl-config生成器，把配置级别拉到“modern”，然后手动删掉任何带`SHA`（不带256）和`CBC`的条目。

还有个容易忽略的坑：有些云负载均衡器默认配置会悄悄降级。阿里云SLB的旧版本策略里，如果选了“安全策略”而不是“自定义”，它会自动添加`AES128-CBC-SHA`作为兜底。你得在控制台里一层层点进去，找到“TLS安全策略”然后选“custom”，才能彻底清干净。这活儿不复杂，但需要耐心——就像清理老房子的墙角蜘蛛网，不搬开柜子永远不知道后面结了多少层。

最后提醒一句：别只看扫描报告里的“漏洞名称”。去服务器上执行`openssl ciphers -v 'HIGH:!aNULL:!eNULL' | grep CBC`，把输出里所有带`CBC`的行都划掉，然后重新测试。如果业务允许，直接上TLS1.3，它从协议层面删除了所有非AEAD套件，一劳永逸。中等强度套件就像汽车的安全带——系着总比不系强，但真撞车时，它只能保证你不飞出去，挡不住侧撞。

(责任编辑：百科)