Defaults.Exposed › 修复 › 现代加密（TLS 版本与密码套件）

如何修复 现代加密（TLS 版本与密码套件）

TLS 是那把锁，它打乱在你访客和你网站之间流动的数据。有两件事让这把锁可信：使用现代版本的 TLS（不是那些老旧、已被攻破的版本），以及使用强壮的密码套件（实际的打乱配方）。本页两者都讲——外加几个不影响你评分、却值得了解的相关设置。

对您业务的关键影响： 如果你的网站跑在过时的加密或孱弱的密码套件上，你客户输入的隐私信息——登录、卡号、联系方式——可能在共享网络上被悄悄拦截读取，而且你会通不过银行、支付处理商和大客户如今在合作前要求的那些安全检查。

这会让您付出什么代价

• 一个客户在酒店或咖啡馆 Wi-Fi 上付款或登录，一个过时的连接或弱密码套件让那个网络上的陌生人读到了他的卡号和密码，而欺诈——以及那通愤怒的电话——直接追溯回你的网站。
• 你申请收取卡支付（或你的支付服务商重新审计你），却因过时的 TLS 或一个被禁的密码套件违反支付安全规则而被拒——你的线上结账被冻结，直到修好。
• 一个大客户的 IT 团队在签约前做例行安全扫描，看到你的网站仍允许已被攻破的加密，把你标为风险——合同就卡在一个零成本就能修好的问题上。
• 一桩数据保护投诉或泄露落到你桌上，监管方问的第一个问题是你是否「恰当地」保护了客户数据——而跑着一个多年来公开已知被攻破的加密，是个非常难给的答案。
• 你的网站显示一把锁，于是所有人都以为它完全安全，这个缺口多年无人察觉——直到一次被拦截的登录或卡号变成一桩远比那个免费修复更昂贵的事故。

为什么它重要。 安全的加密是隐形的；过时或孱弱的加密是一个隐患，安静地待着，直到它害你失去一个客户、一份合同或一次合规通过的那天。TLS 版本和密码套件检查是真正撬动你评分的那两部分，而两者通常都是一个免费设置——把老旧、已被攻破的选项继续开着，没有任何好处。

大白话版

当有人访问你的网站时，他输入的一切——登录、卡号、姓名、电话、消息——都在传输途中被打乱，让陌生人读不到。做这个打乱工作的技术叫 TLS（你也可能听到它的旧名 SSL）。要让这个打乱真正安全，两件事必须对：

1. TLS 版本——你用的是哪一代技术。早期版本（TLS 1.0 和 1.1）多年来已被公开攻破；安全的是 TLS 1.2 和 TLS 1.3。
2. 密码套件——TLS 用来做打乱的具体配方。有些密码套件（比如 RC4、DES 和 3DES）已被破解、如今被禁；现代密码套件仍然强壮。

本页两者都讲，因为一个网站可能一个做对、另一个做错。你可以有一把现代锁却仍开着一个旧的、可破解的配方——或者一个强配方被一把过时的锁保护着。任一缺口都是一扇敞开的门。两者通常都由对你服务器或主机设置的同一个免费改动关上。

这会让你付出什么代价

• 一个客户在公共 Wi-Fi 上被劫。 某人从酒店、咖啡馆或机场登录账户或付款。因为你的网站仍允许一个旧 TLS 版本或一个弱密码套件，同一网络上的陌生人把连接逼降到那个可破解的选项，实时读到了他的密码和卡号。欺诈落在客户身上，但骂名——和那通客服电话——落在你身上。
• 你的卡支付被关掉。 支付安全规则（PCI DSS）要求 TLS 1.2 为最低标准，并明确禁止 RC4 这样的弱密码套件。当你的处理商重新审计你、或当你申请收卡时，一个过时的配置通不过检查，你的结账被冻结，直到修好——恰好在现金流最不该出问题的时刻。
• 一笔生意卡在安全审查里。 在一个大客户签约前，他们的 IT 团队做一次例行扫描。它立刻标记出你的网站仍接受已被攻破的加密——这类发现看起来马虎，让买家怀疑还有什么是松的。合同就为一个零成本就能修好的问题悬在半空。
• 监管方问出那个尴尬的问题。 任何投诉或泄露之后，数据保护机构最先想知道的，就是你是否「恰当地」保护了个人数据。跑着一个多年来公开已知被攻破的加密非常难辩护，而「我们没意识到旧版本还开着」不是一个让人舒服的答案。
• 它在那把锁后面藏了好几年。 因为你的网站仍显示一把正常的锁，没人察觉那个缺口——直到一次被拦截的登录或卡号变成一桩远比那个五分钟修复更昂贵的公开事故。

它到底是什么

TLS 版本

一个网站并不只支持一个 TLS 版本——它能同时提供好几个，让每个访客的浏览器各自挑选。一个现代访客会用可用的最新版本，看到一把正常的锁。危险在于老旧、已被攻破的版本可以作为一扇敞开的后门，待在好版本旁边：攻击者能把访客的连接「降级」到 TLS 1.0 或 1.1，再利用那些版本里已知的弱点（BEAST 和 POODLE 攻击是著名的例子）来解密流量。

所以我们的检查连上你的网站，逐一测试每个版本——TLS 1.0、1.1、1.2 和 1.3——看你的服务器仍接受哪些。下面是「好」长什么样、以及它如何评分：

• TLS 1.3（带或不带 1.2），且没有遗留版本： 最佳结果——一个现代、干净的配置。满分。
• 只有 TLS 1.2，没有 1.3： 安全且通过，但你把最新、最快的版本搁在了一边。多数分；启用 1.3 值得做。
• TLS 1.0 或 1.1 仍被接受： 自动失败，记零分并标为关键——1.2/1.3 也能用并不重要，因为被攻破的版本才是那扇敞开的门。这是你必须修的。

密码套件

版本一旦选定，TLS 就挑一个密码套件——实际打乱数据的算法。多数现代密码套件都强壮。少数已被攻破、绝不能用：RC4（它的打乱有偏、会泄露明文）、DES（密钥太短、可被暴力破解）、3DES（易受「Sweet32」攻击），外加 NULL（根本不加密）、EXPORT 级密码套件（被刻意削弱——FREAK 和 Logjam 攻击）、以及匿名密码套件（不做身份核查，于是冒牌货能坐到中间）。

我们的密码套件检查做两件事。首先它看你的服务器实际与我们协商出的密码套件。然后——这是重要的部分——它主动尝试用几个已知被攻破的密码套件握手（RC4、3DES、EXPORT、NULL 和匿名变体）。一台服务器在和现代客户端对话时可能挑一个强密码套件，却仍在攻击者坚持时接受一个弱的——而那是一个真实的降级风险。如果你的服务器接受任何被禁的密码套件，检查就标记它；接受一个关键的（比如 RC4 或 NULL）则是失败。（在 TLS 1.3 上这里没什么可担心的——那个版本从设计上移除了每一个弱密码套件，所以探测被跳过。）

三个参考性的附加项

有三个相关项目被报告但不影响你的评分——它们被标为参考性，因为它们无法从外部可靠验证，而在任何现代服务器或 CDN 上它们已被正确处理：

• TLS 压缩（CRIME 攻击）： 一个旧特性，若开着，可能让攻击者套出会话 Cookie。它在每个现代 Web 服务器里默认禁用已超过十年，所以今天实质上是个非问题。
• OCSP stapling： 一个性能与隐私上的小妙处，你的服务器预先取来「它的证书未被吊销」的证明，于是每个访客不必自己去问证书机构（那更慢、还泄露浏览数据）。像 Cloudflare 的 CDN 自动做这个。
• 安全重协商： 一个旧缺陷（CVE-2009-3555）的修复，那个缺陷曾让攻击者往会话里注入数据。TLS 1.3 完全移除了重协商，所以在那里是个非问题，而现代 TLS 1.2 服务器默认实现该修复。

我们呈现这些，是为了让你的 IT 人员掌握全貌，但对绝大多数业主而言没什么要做的——你的分数由上面的版本和密码套件检查驱动。

如何修复（免费，约 30 分钟）

把这个交给你的 IT 人员——修复免费。 这一节是给管理你域名、网站或主机的人看的。修复是一个配置改动，不是一笔采购；我们只对长期监控你的加密是否保持正确配置收费。下面这个单一的现代配置一次修好版本和密码套件两项发现。

最简单可靠的办法是生成一份已知良好的配置，而不是手写一份：把你的服务器类型粘进 Mozilla 的 SSL 配置生成器（https://ssl-config.mozilla.org/），选 **「Intermediate」**配置档（广泛兼容）或 「Modern」（仅 TLS 1.3，若你不需要支持任何老旧东西）。它会为你输出正确的 ssl_protocols 和 ssl_ciphers 行。

按平台分：

1. Cloudflare 或托管主机——通常一两下点击。 在 Cloudflare 里：SSL/TLS → Edge Certificates → Minimum TLS Version → TLS 1.2，那里的密码套件由它替你管理（平台不会提供被禁的密码套件）。多数托管主机和建站工具（Squarespace、Wix、Shopify、现代 WordPress 主机）已强制 TLS 1.2+ 加强密码套件——只要确认没有任何「legacy TLS」或「老浏览器兼容」选项还开着。
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';
   ssl_prefer_server_ciphers on;
   

   （TLS 1.3 需要机器上有 OpenSSL 1.1.1+。）
3. Apache。 禁用旧版本并钉一份强密码套件列表，然后重启：

   SSLProtocol all -SSLv3 -TLSv1 -TLSv1.1
   SSLCipherSuite ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384
   SSLHonorCipherOrder on
   

4. Windows / IIS。 用免费的 IIS Crypto 工具（或等效的注册表设置）禁用 TLS 1.0 和 1.1、禁用 RC4/DES/3DES/NULL/EXPORT 密码套件，并保留 TLS 1.2 和 1.3 及强密码套件启用。该工具的「Best Practices」模板一键完成所有这些。
5. 参考性附加项（可选，免费）。 如果你想来个干净彻底：在 Nginx 上加 ssl_stapling on; ssl_stapling_verify on;（带一行 resolver）做 OCSP stapling；在 Apache 上加 SSLUseStapling On。TLS 压缩和安全重协商在现代服务器上已默认安全——无需动作。在 Cloudflare 上这三项都自动处理。
6. 验证，然后回这里重新检测。 确认只剩安全的版本和密码套件——例如用 nmap --script ssl-enum-ciphers -p 443 yourdomain.com，或在 https://ssl-config.mozilla.org/ 链接的工具里测试——然后重新运行本项检查。在可能的地方，把 TLS 1.3 与 1.2 一起启用：它既更快也更安全。

常见错误

• 「我们有一把锁，所以没事。」 那把锁只证明存在一个安全连接。它对一个旧版本或一个被禁的密码套件是否仍在后台被接受只字不提——而那恰恰是这些检查找出的缺口。
• 修了版本却没修密码套件（或反过来）。 禁用 TLS 1.0/1.1 不会自动移除 RC4 或 3DES，钉强密码套件也不会自动禁用旧版本。两个都设——上面生成的配置会做到。
• 留着「legacy」或「老浏览器兼容」开关开着。 许多主机和 CDN 有一个「为了兼容」悄悄重新启用被攻破版本或弱密码套件的选项。它几乎从不帮到一个真实访客，却直接导致这项发现。
• 忘了真正重载/重启服务器。 配置改动在 Web 服务器被重载前不生效——这是一个「已修好」的网站重新检测仍失败的意外常见原因。
• 配了一台服务器却没配全部。 如果你跑着负载均衡、多台 Web 服务器，或分开的子域名（shop、blog、app），每个 TLS 端点都需要相同的配置——攻击者瞄准的是最弱的那个。

要记住什么

TLS 版本和密码套件是你加密中真正撬动评分的那两部分，而两者归根结底都是关掉那些公开已被攻破多年的选项。修复免费，通常每台服务器一行现代配置，而对一个普通访客而言，它除了让连接真正安全之外什么都不改变。相关项目——压缩、OCSP stapling、安全重协商——值得了解，但不会影响你的分数，而在任何现代配置上它们已被替你处理好。

常见问题