TLS_ECDH_RSA_WITH_CAMELLIA_128_CBC_SHA256

各组成部分说明

密码套件规定了客户端和服务器在一次握手中共同使用的一组算法。TLS_ECDH_RSA_WITH_CAMELLIA_128_CBC_SHA256 由 ECDH 密钥交换、RSA 身份认证、Camellia-128-CBC 加密和 SHA256 完整性保护组成。下面逐项说明每个部分及其已知弱点；整体原理可参考密码套件详解。

密钥交换：静态 ECDH。服务器的椭圆曲线 DH 公钥固定在证书里，因此没有前向保密；如果服务器长期复用同一个 ECDH 密钥又不校验客户端发来的点，还会受到无效曲线攻击（Jager、Schwenk、Somorovsky，2015 年）。套件名里的 RSA 是 CA 签发这张 ECDH 证书时用的算法，并不是握手过程中的签名。

加密：Camellia，密钥 128 位，是 NTT 和三菱电机在 2000 年设计的 128 位分组密码，被日本 CRYPTREC 和 ISO/IEC 18033-3 采纳。它被认为与 AES 同样安全，但很少有硬件加速，所以提供它的客户端不多。TLS 套件最早见于 RFC 4132（2005 年），后被 RFC 5932（2010 年）取代，GCM 版本见 RFC 6367（2011 年）。

模式：CBC，先 MAC 后加密。TLS 1.2 及更早版本先对明文计算 HMAC，再填充、加密，接收方必须先解密才能校验完整性。这种顺序催生了一连串填充预言类攻击：针对 TLS 1.0 可预测 IV 的 BEAST（CVE-2011-3389），利用 MAC 校验耗时差异的 Lucky Thirteen（CVE-2013-0169，2013 年），以及利用 SSL 3.0 不校验填充的 POODLE（CVE-2014-3566，2014 年）。RFC 9325（2022 年）规定，除非同时协商了 encrypt_then_mac 扩展（RFC 7366），否则不应（SHOULD NOT）使用 CBC 套件。

完整性：对每条记录计算 HMAC-SHA256，在加密之前进行（先 MAC 后加密）。在 TLS 1.2 中，套件名里的 SHA256 同时指定 PRF 使用的哈希。因此这个套件必须使用 TLS 1.2，不能用于更早的版本。

评级理由

ssl.sh 评级：弱。理由：

• CBC 模式加独立 MAC（先 MAC 后加密），是 Lucky Thirteen 等填充预言攻击的根源，应优先使用 AEAD。
• 没有前向保密：会话密钥由服务器的长期密钥保护（静态 RSA/DH/ECDH、PSK 或 Kerberos），私钥一旦泄露，录下的历史流量都能被解密。

ssl.sh 如何给密码套件评级

哪些 TLS 库支持

以下是 2026-11-10 从各库源码或官方文档读取的 TLS_ECDH_RSA_WITH_CAMELLIA_128_CBC_SHA256 支持情况。“默认启用”指不做任何配置就会协商；“支持，默认关闭”指已经实现，但需要手动打开。

这里跟踪的 9 个库都没有默认启用它。另外实现了它的：OpenSSL 3.5。

NSS 一行是 NSS 库自身的默认值；Firefox 启动时会先关闭 NSS 的全部套件，只重新打开有 security.ssl3.* 或 security.tls13.* 偏好项的那些。Java 的默认状态依据 Oracle 为 JDK 21 记录的 jdk.tls.disabledAlgorithms 默认值推算，后续更新可能会再加限制。OpenSSL 和 GnuTLS 两行只表示是否实现。

历史与标准状态

TLS_ECDH_RSA_WITH_CAMELLIA_128_CBC_SHA256（0xC0,0x78）在 IANA TLS 密码套件注册表中登记，规范文档为 RFC 6367《Addition of the Camellia Cipher Suites to Transport Layer Security (TLS)》（2011 年 9 月，信息类）。BCP 195 中的 RFC 9325（2022 年）规定实现不应（SHOULD NOT）协商静态 DH 或 ECDH 密钥协商，因为两者都没有前向保密。RFC 10015（2026 年）还规定，在 (D)TLS 1.2 中客户端不应提供、服务器不应选择非临时 ECDH 套件，IANA 也把这个条目的 Recommended 值改成了 D。

在 Nginx 和 Apache 中启用或禁用

禁用

从列表里去掉它，或在前面加“!”显式排除。改完后重载服务（nginx -s reload、apachectl graceful）。

# Nginx
ssl_ciphers 'ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:!ECDH-RSA-CAMELLIA128-SHA256';

# Apache httpd (mod_ssl)
SSLCipherSuite ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:!ECDH-RSA-CAMELLIA128-SHA256

如何测试服务器是否接受它

用 openssl s_client 只提供 TLS_ECDH_RSA_WITH_CAMELLIA_128_CBC_SHA256；握手成功就说明服务器接受它：

openssl s_client -connect example.com:443 -tls1_2 -cipher ECDH-RSA-CAMELLIA128-SHA256 </dev/null

握手成功说明服务器接受该套件；出现“no cipher match”或握手失败则说明不接受。

nmap 的 ssl-enum-ciphers 脚本会反复连接，每次只尝试一个套件，最后列出服务器接受的全部套件，并给出 A 到 F 的评级。在输出中查找 TLS_ECDH_RSA_WITH_CAMELLIA_128_CBC_SHA256：

nmap --script ssl-enum-ciphers -p 443 example.com

想解析套件名称或十六进制编号，可以用密码套件查询；SSL 检测会显示线上服务器接受哪些协议版本以及实际协商出的密码套件。