Nginx 中 ssl_ciphers 加密集顺序配置的逻辑解析

Nginx中ssl_ciphers顺序决定TLS 1.2套件优先级，需开启ssl_prefer_server_ciphers on才生效；TLS 1.3套件须前置且硬编码；应分层书写、禁用弱算法、绑定证书类型，并配合ssl_protocols关闭旧协议。

在 Nginx 中，ssl_ciphers 的顺序不是“写在前面就更高级”，而是直接决定 TLS 1.2 握手时实际选用的加密套件——服务端从左到右逐个检查，选第一个客户端也支持的项。这个顺序即安全等级排序，也是防御降级攻击的核心机制。

ssl_prefer_server_ciphers 是前提开关

该指令默认为 off，不显式开启等于无效。只有设为 on，Nginx 才会按你写的 ssl_ciphers 顺序主动选择；否则由客户端挑它喜欢的（哪怕是你列表里靠后、已被淘汰的套件）。

• TLS 1.3 不受此指令影响，其套件由协议硬编码，但该配置仍需保留，保障 TLS 1.2 安全
• 必须放在 server 或 http 块中，避免被其他配置覆盖

TLS 1.2 和 TLS 1.3 套件要分层书写

Nginx 对两个协议的处理逻辑完全不同：TLS 1.3 套件（以 TLS13- 开头）仅用于过滤，且必须显式列出并置于最前；TLS 1.2 套件则依赖顺序匹配，混写或错序会导致协商失败或静默降级。

• 推荐结构：先列 TLS13-AES-256-GCM-SHA384:TLS13-CHACHA20-POLY1305-SHA256:TLS13-AES-128-GCM-SHA256
• 再接 TLS 1.2 套件，全部限定为 ECDHE 或 DHE + AES-GCM / CHACHA20-POLY1305
• 禁止出现 RSA 密钥交换（如 AES128-SHA）、CBC 模式或含 SHA1 的非 AEAD 套件

多证书场景下靠套件类型自动匹配

Nginx 不会为 ECDSA 证书主动切换到 RSA 套件，也不会为 RSA 证书尝试 ECDSA 套件。优先级体现在套件与证书类型的绑定关系上：

• ECDHE-ECDSA-* 类套件只对 ECDSA 证书生效，不匹配则跳过
• ECDHE-RSA-* 类套件只对 RSA 证书生效
• 把 ECDSA 套件放在最前面，支持它的客户端（现代浏览器、iOS/Android 新版本）自然优先走高性能路径；不支持的自动回落到后面的 RSA 套件

弱算法必须从源头剔除

只要 ssl_ciphers 列表里还残留 RC4、3DES、MD5、SHA1、EXPORT、aNULL 等关键词，就等于给降级攻击留了入口——中间人无需破解，只需诱导协商即可触发弱链路。

• 禁用方式不是靠 ! 后缀“补漏”，而是根本不在主列表中出现
• 推荐写法：开头强套件 + 显式剔除（如 !RC4:!MD5:!SHA1:!DES:!3DES:!EXPORT:!aNULL:!eNULL）
• 配合 ssl_protocols TLSv1.2 TLSv1.3 彻底关闭 TLS 1.0/1.1 协议栈