# TLS_DH_DSS_WITH_3DES_EDE_CBC_SHA 密码套件

> TLS_DH_DSS_WITH_3DES_EDE_CBC_SHA（0x00,0x0D）：DH/DSS · 3DES-EDE-CBC · SSL 3.0, TLS 1.0, TLS 1.1, TLS 1.2。ssl.sh 评级：不安全。含 OpenSSL/GnuTLS 名称和 Nginx/Apache 配置。

Source: https://ssl.sh/zh/ciphers/tls-dh-dss-with-3des-ede-cbc-sha/
Last updated: 2026-11-10

TLS_DH_DSS_WITH_3DES_EDE_CBC_SHA（0x00,0x0D）是用于 SSL 3.0, TLS 1.0, TLS 1.1, TLS 1.2 的密码套件：DH 密钥交换、DSS 身份认证、3DES-EDE-CBC 加密、SHA1 消息认证。ssl.sh 评级为“不安全”。

| 字段 | 值 |
|---|---|
| IANA | TLS_DH_DSS_WITH_3DES_EDE_CBC_SHA |
| 十六进制码 | 0x00,0x0D |
| OpenSSL | OpenSSL 3.5 不支持 |
| GnuTLS | - |
| 密钥交换 | DH |
| 身份认证 | DSS |
| 加密算法 | 3DES-EDE-CBC |
| 消息认证（MAC） | SHA1 |
| TLS 版本 | SSL 3.0, TLS 1.0, TLS 1.1, TLS 1.2 |
| 评级 | 不安全 |
| IANA“Recommended” | D |
| 规范 | RFC 5246, RFC 10015 |

## 各组成部分说明

[密码套件](https://ssl.sh/zh/glossary/cipher-suite/)规定了客户端和服务器在一次握手中共同使用的一组算法。TLS_DH_DSS_WITH_3DES_EDE_CBC_SHA 由 DH 密钥交换、DSS 身份认证、3DES-EDE-CBC 加密和 SHA1 完整性保护组成。下面逐项说明每个部分及其已知弱点；整体原理可参考[密码套件详解](https://ssl.sh/zh/learn/cipher-suites/)。

密钥交换：静态（非临时）[Diffie-Hellman](https://ssl.sh/zh/glossary/diffie-hellman/)。服务器的 DH 公钥固定写在证书里，而不是每次握手临时生成，因此没有[前向保密](https://ssl.sh/zh/glossary/forward-secrecy/)；服务器还必须持有一张装着 DH 公钥、而不是普通 RSA 或 ECDSA 公钥的证书。套件名里的 DSS 只表示 CA 用什么算法给这张证书签名。

加密：CBC 模式的 [3DES](https://ssl.sh/zh/glossary/3des/)（三重 DES，EDE）。中间相遇攻击让它名义上 168 位的密钥只剩约 112 位安全强度，而真正的问题是 64 位分组：[Sweet32](https://ssl.sh/zh/glossary/sweet32/)（CVE-2016-2183，Bhargavan 与 Leurent，2016 年）在一条长连接上截获约 785 GB 数据后恢复出了 HTTP Cookie，因为分组数达到约 2^32 时就很可能出现碰撞。NIST 自 2023 年后不再允许用三重 DES 加密。

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

完整性：HMAC-SHA1。[SHA-1](https://ssl.sh/zh/glossary/sha-1/) 已能实际构造碰撞（SHAttered，2017 年），但 HMAC 的安全性并不依赖抗碰撞性，所以 HMAC-SHA1 记录 MAC 并不被认为已被攻破，这个套件的弱点在别处。协商 TLS 1.2 时，密钥派生使用 SHA-256 PRF——[RFC 5246](https://www.rfc-editor.org/rfc/rfc5246)（2008 年）规定所有在它之前定义的套件都这样做。

## 评级理由

- 使用 3DES，64 位分组密码，存在 Sweet32 生日攻击（CVE-2016-2183）。

## 哪些 TLS 库支持

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

| 库 | 状态 | 说明 |
|---|---|---|
| OpenSSL 3.5 | 不支持 | - |
| GnuTLS | 不支持 | - |
| BoringSSL | 不支持 | - |
| Go crypto/tls | 不支持 | - |
| NSS 3.133 | 不支持 | - |
| Firefox | 不支持 | - |
| Java 21 (SunJSSE) | 不支持 | - |
| Windows Schannel (Windows 11 / Server 2022) | 不支持 | - |
| rustls 0.23.46 | 不支持 | - |

这里跟踪的 9 个库都没有默认启用它。没有一个库实现它。

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

- [BoringSSL — ssl/ssl_cipher.cc (main)](https://boringssl.googlesource.com/boringssl/+/refs/heads/main/ssl/ssl_cipher.cc) (2026-11-10)
- [Go — src/crypto/tls/cipher_suites.go (master)](https://github.com/golang/go/blob/master/src/crypto/tls/cipher_suites.go) (2026-11-10)
- [Go — src/crypto/tls/defaults.go (master)](https://github.com/golang/go/blob/master/src/crypto/tls/defaults.go) (2026-11-10)
- [NSS — lib/ssl/ssl3con.c (as vendored in Firefox)](https://github.com/mozilla-firefox/firefox/blob/main/security/nss/lib/ssl/ssl3con.c) (2026-11-10)
- [NSS — TAG-INFO](https://github.com/mozilla-firefox/firefox/blob/main/security/nss/TAG-INFO) (2026-11-10)
- [Firefox — security/manager/ssl/nsNSSComponent.cpp](https://github.com/mozilla-firefox/firefox/blob/main/security/manager/ssl/nsNSSComponent.cpp) (2026-11-10)
- [Firefox — modules/libpref/init/StaticPrefList.yaml](https://github.com/mozilla-firefox/firefox/blob/main/modules/libpref/init/StaticPrefList.yaml) (2026-11-10)
- [Oracle — JDK 21 Providers Documentation: SunJSSE Cipher Suites](https://docs.oracle.com/en/java/javase/21/security/oracle-providers.html#GUID-7093246A-31A3-4304-AC5F-5FB6400405E2) (2026-11-10)
- [Oracle — JDK 21 JSSE Reference Guide: jdk.tls.disabledAlgorithms](https://docs.oracle.com/en/java/javase/21/security/java-secure-socket-extension-jsse-reference-guide.html) (2026-11-10)
- [Microsoft Learn — TLS Cipher Suites in Windows 11](https://learn.microsoft.com/en-us/windows/win32/secauthn/tls-cipher-suites-in-windows-11) (2026-11-10)
- [Microsoft Learn — TLS Cipher Suites in Windows Server 2022](https://learn.microsoft.com/en-us/windows/win32/secauthn/tls-cipher-suites-in-windows-server-2022) (2026-11-10)
- [docs.rs — rustls 0.23.46 crypto::aws_lc_rs (default provider)](https://docs.rs/rustls/0.23.46/src/rustls/crypto/aws_lc_rs/mod.rs.html) (2026-11-10)

## 历史与标准状态

TLS_DH_DSS_WITH_3DES_EDE_CBC_SHA（0x00,0x0D）在 IANA TLS 密码套件注册表中登记，规范文档为 [RFC 5246](https://www.rfc-editor.org/rfc/rfc5246)《The Transport Layer Security (TLS) Protocol Version 1.2》（2008 年 8 月，标准轨道）。RFC 5246 后来已被 [RFC 8446](https://www.rfc-editor.org/rfc/rfc8446)（2018 年） 和 [RFC 9846](https://www.rfc-editor.org/rfc/rfc9846)（2026 年） 废止（obsoleted）。BCP 195 中的 [RFC 9325](https://www.rfc-editor.org/rfc/rfc9325)（2022 年）规定实现不应（SHOULD NOT）协商安全强度低于 128 位的套件，并指出 3DES 只有 112 位。BCP 195 中的 [RFC 9325](https://www.rfc-editor.org/rfc/rfc9325)（2022 年）规定实现不应（SHOULD NOT）协商静态 DH 或 ECDH 密钥协商，因为两者都没有前向保密。[RFC 10015](https://www.rfc-editor.org/rfc/rfc10015)（2026 年）进一步规定，在 (D)TLS 1.2 中客户端绝不能提供、服务器绝不能选择非临时 FFDH 套件，IANA 也把这个条目的 Recommended 值改成了 D。

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

OpenSSL 3.5 无法提供 TLS_DH_DSS_WITH_3DES_EDE_CBC_SHA，openssl s_client 不能直接测试；请使用自带该套件实现的扫描工具。

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

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

想解析套件名称或十六进制编号，可以用[密码套件查询](https://ssl.sh/zh/tools/cipher-suite-lookup/)；[SSL 检测](https://ssl.sh/zh/tools/ssl-checker/)会显示线上服务器接受哪些协议版本以及实际协商出的密码套件。

## 常见问题

### TLS_DH_DSS_WITH_3DES_EDE_CBC_SHA 安全吗？

不安全。ssl.sh 把它评为“不安全”。使用 3DES，64 位分组密码，存在 Sweet32 生日攻击（CVE-2016-2183）。[RFC 10015](https://www.rfc-editor.org/rfc/rfc10015)（2026 年）进一步规定，在 (D)TLS 1.2 中客户端绝不能提供、服务器绝不能选择非临时 FFDH 套件，IANA 也把这个条目的 Recommended 值改成了 D。

### TLS 1.3 能用 TLS_DH_DSS_WITH_3DES_EDE_CBC_SHA 吗？

不能。TLS 1.3 有自己的一套套件，名字里只写 AEAD 和哈希，TLS 1.2 的套件不能用于 TLS 1.3 握手。TLS_DH_DSS_WITH_3DES_EDE_CBC_SHA 适用于 SSL 3.0, TLS 1.0, TLS 1.1, TLS 1.2。最接近的 TLS 1.3 套件是 [TLS_AES_128_GCM_SHA256](https://ssl.sh/zh/ciphers/tls-aes-128-gcm-sha256/)，TLS 1.3 会另外协商 X25519 等密钥交换与它搭配。

### 在 Nginx 或 Apache 里怎么禁用 TLS_DH_DSS_WITH_3DES_EDE_CBC_SHA？

不需要禁用：Nginx 和 Apache httpd 通常使用的 OpenSSL 3.5 根本没有实现 TLS_DH_DSS_WITH_3DES_EDE_CBC_SHA，它们无法协商这个套件。

### 哪些客户端和库还支持 TLS_DH_DSS_WITH_3DES_EDE_CBC_SHA？

不支持：OpenSSL 3.5、GnuTLS、BoringSSL、Go crypto/tls、NSS 3.133、Firefox、Java 21 (SunJSSE)、Windows Schannel (Windows 11 / Server 2022) 和 rustls 0.23.46。