跳转至

5.5 程序结构——闲聊 HTTPS（网络安全加餐）

内容梗概

这是正课结束后的“闲聊”加餐（老师明确表示不感兴趣的同学可以跳过），围绕两件发生在课程中的真实事件展开科普：一是之前为什么要求大家改 hosts 文件才能上 GitHub 交作业；二是前一天课程网站打不开、浏览器提示“证书不受信任/可能遭到中间人攻击”是怎么回事。由此讲了域名与 IP、DNS 解析与缓存、hosts 文件的优先级、CDN 内容分发网络，再深入讲了 HTTP 明文传输的风险、对称/非对称加密（公私钥对）、HTTPS 的简化握手流程（随机数 RC/RS、CA 证书、Premaster 密钥交换），以及中间人攻击的原理和为什么会被浏览器发现。课上还用 Wireshark 现场抓包演示了 HTTP 流量完全可见。

知识点详解

域名、DNS 与 hosts 文件

  • github.com 是域名，classroom.github.com 是它的**子域名**（逻辑上归属于主域名）(约 00:41)。
  • 访问域名时，系统先去 DNS 服务器（域名解析服务器）把域名翻译成 IP 地址；可用 cmd 里 ping github.com 看到实际访问的 IP (约 01:25)。
  • 系统有 DNS 缓存：第一次解析后存下来，之后直接查缓存，不再访问 DNS (约 01:55)。
  • hosts 文件 (约 02:41)：路径 C:\Windows\System32\drivers\etc\hosts，可用 VS Code 打开。写法为 IP 域名（IP 加空格加域名），其**优先级高于缓存和 DNS 解析**——写了之后系统所有程序访问该域名都会强行访问指定 IP。
  • 例子：hosts 里写 127.0.0.1 taobao.com，淘宝就打不开了（访问的是你自己）。
  • 为什么要改 hosts 交作业：一个域名可对应多个 IP（多台服务器），为的是 CDN 内容分发网络——服务商在离用户近的地方部署内容相同的服务器，访问更快；DNS 解析时会给你离你近的 IP。但有时“近而快”的 IP 因特殊原因访问不了，反而远一点的能访问，于是师兄师姐测出能用的 IP 发给大家，用 hosts 强行指定；classroom 子域名也有自己的一组 IP 需要分别指定 (约 07:32–12:33)。

HTTP 的风险与抓包演示

  • 早期上网用 HTTP，通信过程**没有任何加密**，数据在网上“裸奔” (约 15:15)。
  • 风险场景：有人在宿舍开一个与校园网同名的 WiFi 热点（如 CUC），你的电脑可能因信号强自动连上，所有流量都经过这个“中间人”。
  • 演示 (约 17:15)：用 Wireshark 过滤 http 协议，访问传媒大学官网（by.cuc.edu.cn），抓包器里能清楚看到访问的 IP、加载的文件、User-Agent 等所有数据。

对称加密与非对称加密（公私钥对）

  • 对称加密：双方用同一个密码（如 password）加密和解密。问题：双方怎么安全地约定同一个密码？全世界广播就没意义了 (约 19:15)。
  • 非对称加密（公私钥对）：每人有一对**公钥 public** 和**私钥 private**；用公钥加密的东西只有对应私钥能解开。公钥可以发出去，私钥必须自己保管 (约 20:08–23:09)。
  • 联系实际：之前配置 GitHub 时生成的密钥对就是这个机制；把私钥（如 ppk 文件）删了就再也 SSH 连不上 GitHub，因为公钥存在服务器上无法配对，只能重新配置。

HTTPS 简化握手流程 (约 24:05–32:28)

  1. 浏览器（client）向服务器发 client hello：声明要进行 HTTPS 通信、告知自己支持哪些对称加密算法，并附一个随机字符串 RC（将来密钥的一部分）。
  2. 服务器回 server hello：选定某个加密算法 A，也回一个随机字符串 RS。此时双方都有 RC 和 RS（但这两个值没加密，中间偷听者也能拿到）。
  3. 服务器发送**证书**和**公钥 S** 给浏览器。证书不是随便生成的，需要向第三方 **CA 机构**申请。浏览器用 CA 验证证书是否合法可信——不可信就报警阻止访问。
  4. 证书可信后，浏览器随机生成 Premaster（密钥的第三部分），用服务器公钥 S 加密后发给服务器；中间人没有 S 的私钥，无法解出 Premaster。
  5. 双方各自用 RC + RS + Premaster 拼出最终密钥 password，之后互发一条加密消息验证（能解出“你好”说明密钥一致），后续通信全部用这个对称密钥加密。

小结：HTTPS = 用非对称加密（公私钥对+CA 证书）完成**对称密钥的安全交换**，之后用对称加密通信。

中间人攻击 (约 33:07–39:05)

  • 原理：中间人通过 WiFi 劫持等手段插在你和服务器之间，两头骗——对服务器冒充你、对你冒充服务器。前两步的 RC、RS 他都能监听拿到。
  • 关键一步：服务器发证书和公钥时，中间人不能直接转发真证书（那样他就解不开后续数据），于是**自己伪造一个证书**，把自己的公钥 M 发给你。你用 M 的公钥加密 Premaster 发出去，他用 M 的私钥解开，再用 S 的公钥加密转给服务器——从此他掌握全部密钥，可以窃听甚至篡改你的数据。
  • 为什么会暴露：证书是伪造的，颁发者/组织单位与真正 CA 颁发的不一样，浏览器验证不通过，地址栏小锁变红、提示“证书无效/可能遭到中间人攻击”，Chrome 会直接禁止访问。这就是前一天课程网站打不开的原因（老师顺带吐槽：涉事者居然用 QQ 邮箱还被“人肉”了，不过他也可能是证书被盗的受害者）。

示例与演示

  • ping github.com 查看域名解析出的 IP；打开 hosts 文件（C:\Windows\System32\drivers\etc\hosts）展示格式。
  • Wireshark 现场抓包：过滤 http 协议后访问传媒大学官网，展示 HTTP 流量内容完全可见。
  • 白板画图：CDN 就近访问示意、HTTPS 简化握手全流程（client hello/server hello/证书+公钥/Premaster/对称通信）、中间人两头骗流程。

重点与难点

  • hosts 文件优先级高于 DNS 和缓存，可强行指定域名对应的 IP——这是解决 GitHub 访问问题的原理，也是被利用来“劫持”的手段。
  • 一个域名对应多个 IP 是为了 CDN 加速；DNS 一般会给你近而快的 IP，但“近”不等于“能通”。
  • 公钥加密私钥解、公钥可公开私钥须保密——非对称加密的全部关键就在这一句。
  • HTTPS 的核心不是全程非对称加密，而是**用非对称加密安全地交换对称密钥**。
  • 中间人攻击的命门在于伪造证书通不过 CA 验证——看到“证书不受信任”的警告一定要警惕，不要强行继续访问。

关联内容

  • 本课是补充/闲聊性质，与 Python 语法无直接关系，属于计算机网络与网络安全的科普。
  • 呼应课程实际：解释改 hosts 交作业（GitHub Classroom）和课程网站证书报警两个真实事件；配置 GitHub 时生成的公私钥对在提交作业章节用过。
  • 正式知识（DNS、TCP/TLS 握手细节、密码学）留待后续《计算机网络》《密码学》等专业课；5.6 的 Base64 与邮件协议（SMTP/MIME）也同属网络应用话题。