密码套件 · 0xD0,0x05
TLS_ECDHE_PSK_WITH_AES_128_CCM_SHA256
TLS_ECDHE_PSK_WITH_AES_128_CCM_SHA256(0xD0,0x05)是用于 TLS 1.2 的密码套件:ECDHE 密钥交换、PSK 身份认证、AES-128-CCM 加密、AEAD 消息认证。ssl.sh 评级为“安全”。
详细信息
- IANA 名称
TLS_ECDHE_PSK_WITH_AES_128_CCM_SHA256- 十六进制码
0xD0,0x05(53253)- OpenSSL
ECDHE-PSK-AES128-CCM(OpenSSL 3.5 手册中列出,我们的测试构建未启用)- GnuTLS
- GnuTLS 未实现
- 密钥交换
- ECDHE
- 身份认证
- PSK
- 加密算法
- AES-128-CCM AEAD
- 消息认证(MAC)
- AEAD · 哈希 SHA256
- TLS 版本
- TLS 1.2
- IANA“Recommended”
- Y:IETF 推荐 · DTLS-OK: Y
- 规范
- RFC 8442
各组成部分说明
密码套件规定了客户端和服务器在一次握手中共同使用的一组算法。TLS_ECDHE_PSK_WITH_AES_128_CCM_SHA256 由 ECDHE 密钥交换、PSK 身份认证、AES-128-CCM 加密和 AEAD 完整性保护组成。下面逐项说明每个部分及其已知弱点;整体原理可参考密码套件详解。
密钥交换:ECDHE_PSK。双方用预共享密钥互相认证,再叠加一次临时 ECDHE 交换,不用证书也能获得前向保密。最早的 ECDHE_PSK 套件见 RFC 5489(2009 年),面向 TLS 1.2 的 AES-GCM 和 AES-CCM 版本随后由 RFC 8442(2018 年)补充。
加密:AES,密钥 128 位,是 FIPS 197(2001 年)规定的 128 位分组密码。大多数服务器和手机 CPU 都有 AES 指令(x86 的 AES-NI、ARMv8 的密码扩展),速度快,也避开了查表式软件实现的缓存计时泄露。
模式:CCM(计数器模式加 CBC-MAC),一种 AEAD,认证标签 16 字节。它只用到分组密码的加密函数,适合有硬件分组密码、却不支持 GCM 的小型设备。RFC 6655(2012 年)为 TLS 1.2 定义了 AES-CCM 套件,RFC 7251(2014 年)补充了 ECDHE-ECDSA 版本。
完整性:没有单独的 MAC,每条记录都由 AEAD 认证标签保护。套件名末尾的 SHA256 指定 TLS 1.2 PRF 使用的哈希,用于派生密钥和计算 Finished 消息。
评级理由
ssl.sh 评级:安全。理由:
- 临时密钥交换(有前向保密)加 AEAD 加密,正是 TLS 1.2 最佳实践要求的组合。
哪些 TLS 库支持
以下是 2026-11-10 从各库源码或官方文档读取的 TLS_ECDHE_PSK_WITH_AES_128_CCM_SHA256 支持情况。“默认启用”指不做任何配置就会协商;“支持,默认关闭”指已经实现,但需要手动打开。
| 库 | 状态 | 说明 |
|---|---|---|
| OpenSSL 3.5 | 已实现 | 套件字符串 ECDHE-PSK-AES128-CCM; 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 个库都没有默认启用它。另外实现了它的:OpenSSL 3.5。
NSS 一行是 NSS 库自身的默认值;Firefox 启动时会先关闭 NSS 的全部套件,只重新打开有 security.ssl3.* 或 security.tls13.* 偏好项的那些。Java 的默认状态依据 Oracle 为 JDK 21 记录的 jdk.tls.disabledAlgorithms 默认值推算,后续更新可能会再加限制。OpenSSL 和 GnuTLS 两行只表示是否实现。
历史与标准状态
TLS_ECDHE_PSK_WITH_AES_128_CCM_SHA256(0xD0,0x05)在 IANA TLS 密码套件注册表中登记,规范文档为 RFC 8442《ECDHE_PSK with AES-GCM and AES-CCM Cipher Suites for TLS 1.2 and DTLS 1.2》(2018 年 9 月,标准轨道)。注册表把它标为推荐(Y)。
在 Nginx 和 Apache 中启用或禁用
启用
两者都使用 OpenSSL 名称。下面的片段保留一组现代套件并加上本套件;TLS 1.3 套件与 TLS 1.2 列表分开配置。宝塔面板用户可在站点的“配置文件”里修改同样的指令。
# Nginx
ssl_protocols TLSv1.2 TLSv1.3;
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:ECDHE-PSK-AES128-CCM';
ssl_prefer_server_ciphers off;
# Apache httpd (mod_ssl)
SSLProtocol -all +TLSv1.2 +TLSv1.3
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:ECDHE-PSK-AES128-CCM
SSLHonorCipherOrder off
禁用
从列表里去掉它,或在前面加“!”显式排除。改完后重载服务(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:!ECDHE-PSK-AES128-CCM';
# 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:!ECDHE-PSK-AES128-CCM
如何测试服务器是否接受它
用 openssl s_client 只提供 TLS_ECDHE_PSK_WITH_AES_128_CCM_SHA256;握手成功就说明服务器接受它:
openssl s_client -connect example.com:443 -tls1_2 -cipher ECDHE-PSK-AES128-CCM </dev/null
握手成功说明服务器接受该套件;出现“no cipher match”或握手失败则说明不接受。
nmap 的 ssl-enum-ciphers 脚本会反复连接,每次只尝试一个套件,最后列出服务器接受的全部套件,并给出 A 到 F 的评级。在输出中查找 TLS_ECDHE_PSK_WITH_AES_128_CCM_SHA256:
nmap --script ssl-enum-ciphers -p 443 example.com
想解析套件名称或十六进制编号,可以用密码套件查询;SSL 检测会显示线上服务器接受哪些协议版本以及实际协商出的密码套件。
常见问题
TLS_ECDHE_PSK_WITH_AES_128_CCM_SHA256 安全吗?
从密码学上看是安全的:ssl.sh 把它评为“安全”。临时密钥交换(有前向保密)加 AEAD 加密,正是 TLS 1.2 最佳实践要求的组合。
TLS 1.3 能用 TLS_ECDHE_PSK_WITH_AES_128_CCM_SHA256 吗?
不能。TLS 1.3 有自己的一套套件,名字里只写 AEAD 和哈希,TLS 1.2 的套件不能用于 TLS 1.3 握手。TLS_ECDHE_PSK_WITH_AES_128_CCM_SHA256 适用于 TLS 1.2。最接近的 TLS 1.3 套件是 TLS_AES_128_CCM_SHA256,TLS 1.3 会另外协商 X25519 等密钥交换与它搭配。
在 Nginx 或 Apache 里怎么启用 TLS_ECDHE_PSK_WITH_AES_128_CCM_SHA256?
把 ECDHE-PSK-AES128-CCM(它的 OpenSSL 名称)加进 Nginx 的 ssl_ciphers 或 Apache httpd 的 SSLCipherSuite,同时在 ssl_protocols 或 SSLProtocol 中保留 TLS 1.2,然后重载服务。完整片段见上面的配置部分。
哪些客户端和库还支持 TLS_ECDHE_PSK_WITH_AES_128_CCM_SHA256?
已实现、默认状态未跟踪: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。
更好的替代
使用 AES-128-CCM 的其他套件
| IANA 名称 | 密钥交换 | 认证 | 评级 |
|---|---|---|---|
| TLS_RSA_WITH_AES_128_CCM | RSA | RSA | |
| TLS_DHE_RSA_WITH_AES_128_CCM | DHE | RSA | |
| TLS_PSK_WITH_AES_128_CCM | PSK | PSK | |
| TLS_DHE_PSK_WITH_AES_128_CCM | DHE | PSK | |
| TLS_ECDHE_ECDSA_WITH_AES_128_CCM | ECDHE | ECDSA |
资料来源
- IANA — TLS Cipher Suites registry
- OpenSSL 3.5 — openssl-ciphers(1)
- GnuTLS — lib/algorithms/ciphersuites.c
- BoringSSL — ssl/ssl_cipher.cc (main) (2026-11-10)
- Go — src/crypto/tls/cipher_suites.go (master) (2026-11-10)
- Go — src/crypto/tls/defaults.go (master) (2026-11-10)
- NSS — lib/ssl/ssl3con.c (as vendored in Firefox) (2026-11-10)
- NSS — TAG-INFO (2026-11-10)
- Firefox — security/manager/ssl/nsNSSComponent.cpp (2026-11-10)
- Firefox — modules/libpref/init/StaticPrefList.yaml (2026-11-10)
- Oracle — JDK 21 Providers Documentation: SunJSSE Cipher Suites (2026-11-10)
- Oracle — JDK 21 JSSE Reference Guide: jdk.tls.disabledAlgorithms (2026-11-10)
- Microsoft Learn — TLS Cipher Suites in Windows 11 (2026-11-10)
- Microsoft Learn — TLS Cipher Suites in Windows Server 2022 (2026-11-10)
- docs.rs — rustls 0.23.46 crypto::aws_lc_rs (default provider) (2026-11-10)
- RFC Editor — RFC index
- Nmap — ssl-enum-ciphers