5-8 Web 网站的安全性可通过加密图标确认 · 波仔的网络与信息安全课

📄 一句话概括

浏览器地址栏那个挂锁只说明一件事——你和这台服务器之间的路被加密了；它完全不说明这台服务器是好人的，所以"看有没有锁"这个流传多年的建议，今天已经是一条会害人的建议。

📝 本节和前面几节的关系

5-7 讲了 HTTPS 内部是怎么工作的（混合加密 + TLS 握手），这一节换到用户视角：站在浏览器前面，这些技术最后呈现成了什么、又能被误读成什么。

它也是本章的"验收环节"：证书（5-4）、签名（5-6）、混合加密（5-7）最后全部浓缩成地址栏右上角一个小图标——而这个小图标能表达的，比它看起来的少得多。

一、挂锁到底承诺了什么：一张对照表

挂锁能证明	挂锁不能证明
你和这台服务器之间的数据被加密了	这台服务器是好人的
路上没人能偷看、篡改传输内容	网站内容是真的、合法的
证书里的域名与地址栏域名一致	公司是真实存在的
	数据到了那边会被怎么处理

一句话概括：挂锁管的是【管道】，不是【站在管道那头的人】。

这个区分为什么重要：它把"传输安全"和"站点可信"这两件事切开了。前者是密码学能保证的（5-7），后者密码学给不了任何保证——你要判断"这个网站是不是在骗我"，得靠别的东西：域名拼写、是不是自己主动输入的地址、这个请求是不是自己预期的。

二、动手 Demo：挂锁的能力边界

# 挂锁能证明的 vs 不能证明的（对照三张表）
rows = [("你和这台服务器之间的数据被加密了", "这台服务器是好人的"),
        ("路上没人能偷看、篡改传输内容",     "网站内容是真的、合法的"),
        ("证书里的域名与地址栏域名一致",     "公司是真实存在的")]

# 免费证书让"有锁"变得毫无门槛
#   证书要不要钱 → 不要钱
#   申请要多久   → 秒级自动签发
#   审核什么     → 只证明【你控制这个域名】
#   钓鱼网站有没有锁 → 绝大多数都有

实跑输出：

一、挂锁只说明一件事：这条路被加密了
  挂锁能证明                        挂锁不能证明
  你和这台服务器之间的数据被加密了  这台服务器是好人的
  路上没人能偷看、篡改传输内容      网站内容是真的、合法的
  证书里的域名与地址栏域名一致      公司是真实存在的
                                    数据到了那边会被怎么处理
  → 一句话：挂锁管的是【管道】，不是【站在管道那头的人】。

二、页面里混进一个 http 资源，挂锁就掉了
  页面本身  里面的资源            浏览器表现
  https     全部 https            完整挂锁
  https     有 http 图片 / 脚本   锁变灰或提示【不安全】
  https     脚本是 http 且遭改写  加密形同虚设（攻击者可改脚本）
  → 所以 HTTPS 站点要求【全页 HTTPS】，任何一处回退都会破坏整页的保证。

三、免费证书让【有锁】变得毫无门槛
  环节                          2026 的状况
  证书要不要钱                  不要钱（Let's Encrypt 等免费 CA）
  申请要多久                    秒级自动签发，无人工审核
  审核什么                      只证明【你控制这个域名】，不查你是谁、干什么
  钓鱼网站有没有锁              绝大多数都有——这正是它被滥用的方式

四、2026 的实际数字（Cloudflare 口径，2026-07）
  人类流量中加密的比例                    98.9%
  TLS 1.3 占比                            65.9%（另一份扫描口径约 78%）
  TLS 1.2 占比                            2.68%（一年内腰斩）
  TLS 1.0 占比                            0.01%（事实退役）
  后量子密钥协商：浏览器端支持            69.94%
  后量子密钥协商：源站支持                9.37%
  → 加密【有没有】这个问题已经结束；现在要问的是加密【够不够好】：
     证书健康度、TLS 版本下限、HSTS 是否真的生效。

五、EV 证书的绿色公司名为什么不显示了
  · EV 证书做了更严格的企业身份核验，曾经在地址栏显示绿色公司名
  · 2019 年 Chrome 移除这一视觉标记，Safari 与 Firefox 随后跟进
  · 原因很直接：用户并没有据此分辨网站的可靠性
  → 结果就是：现在从地址栏看，一张免费 DV 证书与一张严格核验的
     EV 证书长得一模一样。绿色标识的那条路，市场已经判定走不通。

读这个输出：

第二段是本节最实用的一条：HTTPS 页面里只要混进一个 http 资源，整页的保护就被破坏。这个现象叫混合内容（mixed content）——更危险的是"脚本是 http"那一行：攻击者可以改写这个脚本，等于在你的加密页面里塞进了他自己的代码，此时挂锁可能还在，但加密已经形同虚设。 所以部署 HTTPS 的目标从来不是"主页面是 https"，而是"全页 https"——这也正是"全 SSL 保护"这个说法的实际含义。
第四段那句"加密有没有这个问题已经结束"很值得记：人类流量加密比例已经 98.9%——所以再拿"我们支持 HTTPS"当卖点已经没有意义。今天的差距在质量上：证书是不是会自动续期、TLS 版本下限是多少、HSTS 有没有真正生效。 这三项都有大量网站还没做到。
第五段的 EV 故事是一个"设计意图被用户行为打败"的经典案例：浏览器一度想用绿色公司名来区分"经过严格核验的身份"，结果用户并不据此判断，2019 年被 Chrome 移除，其他浏览器跟进。 从那以后，从地址栏看，一张免费证书和一张严格核验的证书长得完全一样——这直接意味着"看锁判断可信度"这条路在视觉上已经被浏览器自己封死了。

三、SSL 加速器：把加密的算力开销从服务器上搬走

教材里提到的"SSL 加速器"，指的是专门用来做 TLS 加解密运算的硬件或独立设备。它的存在理由很直接：在 HTTPS 早期，加解密对服务器 CPU 是实打实的负担（每一次新连接都要做一次公钥运算，那是本节前面实测过的"几十毫秒"级别的工作）。

今天这个需求的形态已经变了：

CPU 里普遍带有 AES 硬件指令，对称加密的开销被大幅摊薄；
公钥运算的负担主要落在"新连接的建立"上，而不是数据量上——所以优化的重点变成了"减少握手次数"（连接复用、TLS 1.3 把握手压到一个往返）；
真正需要专用加速的场景仍然存在：硬件安全模块（HSM）负责密钥不出设备、负载均衡器与 CDN 边缘节点承担 TLS 卸载。

所以"SSL 加速器"这个概念今天更多体现为"TLS 卸载"与"边缘终结"：把加解密从应用服务器挪到前置的负载均衡或 CDN 上，服务器专心处理业务逻辑。

四、⚠️ 2026 现状

【"看有没有锁"这条建议必须停用】。 免费 CA 让证书变成零成本、秒级可得，而证书只验证"你控制这个域名"——结果是绝大多数钓鱼网站都有合法的挂锁。正确的习惯是看完整域名：paypa1.com（数字 1 代替字母 l）、amazon-account-verify.com、yourbank-secure-login.net 这类域名可以有完全合法的证书。并且：不要点邮件或短信里的登录链接，用自己保存的书签或手动输入地址。
【加密本身已经不是差距，质量才是】。 98.9% 的人类流量已加密，TLS 1.3 占约 65.9%~78%，TLS 1.2 已降到 2.68%。与此同时，后量子密钥协商的客户端支持率 69.94%、源站只有 9.37%——这个 7.5 倍的差距，就是接下来两三年最明确的工作量（5-9）。
【证书管理正在从"一年一次"变成"每月几次"】。 2026-03-15 起最长有效期降到 200 天，2027 年 100 天，2029 年 47 天。在 47 天周期下，100 张证书约等于每年 800 次续期——手工方案直接失效。所以现实里的结论是：上 ACME 自动化不是优化项，而是入场券（机制细节见 5-10）。
【企业网络里还有一个反直觉的现象：挂锁在你公司电脑上可能不成立】。 很多企业会在受管设备上安装自己的根证书，用网关解密并检查 HTTPS 流量——这叫 TLS 拦截，本质上是一次被授权的中间人。端点用户看到挂锁照常，但流量在公司网关处已被解密。 而且这类做法常常带来安全副作用：一项对 80 多亿条被拦截连接的研究发现，62% 的拦截连接安全性低于不拦截时，58% 带有严重漏洞（完整讨论见 5-14）。

30 秒实验

今天做两个动作，各 15 秒：

打开浏览器开发者工具的"安全"面板，点开"查看证书"：看"颁发给"这一栏的域名是不是你正在访问的域名。然后刻意记住一件事：如果这一栏写着某个陌生的公司名或你单位的名字，说明有中间设备在解密你的流量——这个动作能让你亲眼看到"挂锁存在"和"端到端"是两件不同的事。
想一个具体的钓鱼场景并自问：收到一封"银行"邮件，链接指向 yourbank-secure-login.net，打开后地址栏有锁——你会输入密码吗？——正确答案是不输入：域名不是银行的，锁只说明你和这个骗子的连接是加密的。记住的判断顺序是：先看域名，再看锁。

这一节要带走的一句是：HTTPS 的意义是把"路上"变成安全的，它从来没有、也不可能把"对面是谁"变成安全的——挂锁是一张"这段路是密封的"证明，不是一张"对面是好人"的证书。

常见误区

错误：有挂锁就说明这个网站是安全的，可以放心输入信息。——纠正：挂锁只证明"这段连接被加密"，不证明"这个网站值得信任"。它现在几乎没有任何鉴别力：免费 CA 在几秒内就能给任何域名签发一张完全合法的证书，而绝大多数钓鱼网站都已经这么做了。所以正确的判断顺序是"先看完整域名，再看锁"——域名不对，锁再亮也不能输入。反过来说，域名对但没锁（http）才是真正该退出的情况——那种情况下连传输安全都没有。
错误：页面是 https 的，那这个页面上的所有内容都是安全加载的。——纠正：不一定，这就是混合内容（mixed content）。只要页面里有一个子资源走 http，整页的保护就被削弱：图片是 http，攻击者能替换图片（冒充攻击的一种）；脚本是 http，攻击者能直接改写代码——而后者等于让攻击者在你的加密页面里执行任意逻辑，挂锁这时已经形同虚设。所以"全 SSL 保护"的标准是全页所有元素都走 https——部署时的检查点也应该是"有没有任何一个 http 资源"，而不是"主页面是不是 https"。
错误：EV 证书是最高级的证书，看到绿色标志就可以放心。——纠正：这个视觉标志从 2019 年起就已经不显示了。Chrome 在 2019 年移除地址栏的 EV 绿色公司名，Safari 和 Firefox 随后跟进，理由是研究显示用户并没有据此判断网站可信度。结果是从外观上再也区分不出"免费 DV 证书"和"严格核验的 EV 证书"。所以"按证书等级判断可信度"这条路在界面上已经被封死——需要可信判断的场景，靠的是"自己收藏的入口"和"多因素认证"，不是证书外观（5-14 里讲抗钓鱼认证时会更直接地讲这一点）。
错误：证书自动化（ACME）只是运维的便利工具，不做也能凑合。——纠正：在 47 天有效期的时间表下，它已经从"便利"变成"必需"。算一笔账就明白：100 张证书在 47 天周期下约 800 次续期/年；如果每次手工处理按 2 小时计，就是每年约 1600 个工时——这相当于一个全职工位。 而且手工流程的风险不只是"花时间"：漏掉一张证书的后果是服务中断（浏览器直接报"连接不安全"）。所以"能不能自动续期"应该作为选型与架构设计的一个基本条件，而不是上线之后再补的功能。

自测三问（点开对答案）

1. 为什么说"看有没有挂锁"这条建议今天会害人？ —— **因为挂锁的含义从来比它看起来窄**：**它只证明"这段连接被加密"，即"传输过程没人偷看或篡改"**——**它不证明域名属于谁、不证明运营者是正规公司、不证明网站不会收集并滥用你的数据**。**而在免费 CA 普及之后，这层含义几乎失去了鉴别力**：**任何一个攻击者注册一个形近域名，几秒钟就能拿到一张合法证书，挂锁照常显示**。**继续教人"看到锁就放心"，等于教人用一个已经失效的信号做判断**。**正确的替代习惯是两条**：**① 看完整的域名（有没有拼写异常、有没有多余的子域名）；② 不要从邮件链接进入登录页，用自己保存的入口。** 2. 一个 https 页面里混进了一个 http 的脚本，会发生什么？ —— **整页的保护会被削弱到几乎无效**。**因为脚本可以在页面里执行任意逻辑**——**攻击者在中间改写这个 http 脚本后，就能读取页面上的一切、篡改页面内容、甚至窃取其他安全请求的数据**。**此时挂锁可能还在（浏览器对混合内容的处理方式不完全一致），但"端到端加密"这个承诺已经不成立了**。**这就是为什么 HTTPS 的正确目标不是"主页面是 https"，而是"全页所有资源都是 https"**——**也就是教材里说的"全 SSL 保护"。** 3. "SSL 加速器"今天还有意义吗？ —— **作为"专门插一块卡来加速加解密"的原始形态，它的必要性已经大大下降**，**因为 CPU 普遍内置了 AES 硬件指令，对称加密的开销被摊薄了**。**但这个需求本身没有消失，只是换了形式**：**今天的重点在"把 TLS 处理从应用服务器卸载到前置设备或 CDN 边缘"，以及"用硬件安全模块保证私钥不出设备"。** **优化目标也变了**：**在数据量大时瓶颈是对称加密（现在已不成问题），而在连接多时瓶颈是握手（新连接的建立），所以真正的杠杆是 TLS 1.3、连接复用和边缘终结。** **换句话说：从"算得更快"转向了"少算几次"。**

☐ 下一节（5-9 安全性更高的加密）