去年帮一个朋友看他的文传小电商站，打开浏览器开发者工具，输处Network 面板里一眼扫过去，文传登录请求的输处 Payload 明晃晃写着 `username=admin&password=123456`。不是文传 base64，不是输处哈希，就是文传裸的。我问他知不知道这意味着什么，输处他说“不是文传有 HTTPS 吗”。问题是输处他那个页面是从 HTTP 跳过来的，跳转前的文传那一次请求，密码已经发出去了。输处

Web 明文传输这件事，文传核心就一句话：数据从浏览器到服务器的输处路上，任何中间节点都能看到。文传中间节点包括你连的那个咖啡店 WiFi 路由器、运营商的骨干网设备、公司出口的代理服务器。HTTP 协议本身不加密，TCP 包里的内容就是纯文本，用 Wireshark 抓一下，HTTP 请求体直接可读。

先搞清楚哪些地方在裸奔

不只是登录表单。Cookie 里的 Session ID 如果没设 Secure 和 HttpOnly 标志，每次 HTTP 请求都会带上它，攻击者抓到一个有效的 Session ID 就能直接冒充用户。API 接口返回的 JSON 数据、上传的文件内容、甚至 URL 里的查询参数（比如 `?token=xxx`），全都是明文。

有个容易忽略的点：混合内容。页面本身是 HTTPS 加载的，但里面引用了一个 HTTP 的图片或脚本。浏览器地址栏可能还显示锁图标，但那个 HTTP 请求的内容对中间人完全透明。Chrome 从 2020 年开始逐步拦截混合内容，但很多老站还在踩这个坑。

HTTPS 是基本盘，但配置不对等于白搭

上 HTTPS 不是买个证书就完事了。我见过配置了 SSL 但同时支持 TLS 1.0 和 SSL 3.0 的服务器，这两个版本都有已知的严重漏洞（POODLE、BEAST）。正确做法是只启用 TLS 1.2 及以上，用 Mozilla 的 SSL Configuration Generator 生成配置直接套。

HSTS 响应头也得加。没有 HSTS 的话，用户第一次访问 `http://example.com`，浏览器会先发一个明文请求，服务器再 301 跳到 HTTPS。那第一次请求就是明文，攻击者可以在这个窗口做 SSL Strip。HSTS 告诉浏览器“这个域名以后只走 HTTPS”，但第一次访问仍然需要服务器先响应一次。所以更彻底的做法是把自己的域名提交到 HSTS Preload List，让浏览器内置这个规则，第一次访问就直接走 HTTPS。

证书本身也有讲究。自签名证书在浏览器里会弹警告，用户点“继续访问”之后，加密通道虽然建立了，但中间人可以伪造证书，用户根本分辨不了。Let's Encrypt 现在免费签发 DV 证书，自动化续期用 certbot 一条命令搞定，没有任何理由再用自签名。

代码层面能做的事

密码字段在传输前做一次客户端哈希，比如用 SHA-256 加盐，这样即使被截获，攻击者拿到的也不是原始密码。但这不能替代 HTTPS，因为哈希值本身可以被重放。它的价值在于防止密码在多个站点间被撞库。

Cookie 设置 `Secure` 标志，确保只在 HTTPS 连接中发送。`SameSite=Lax` 或 `Strict` 能防 CSRF，间接减少明文传输被利用的场景。对于特别敏感的操作，比如支付确认，可以在应用层再加一层加密，用 Web Crypto API 在浏览器端加密数据，服务端用对应私钥解密。这层额外加密的意义在于：即使 TLS 在某处被终止（比如 CDN 回源到源站的那一段），数据仍然是密文。

CDN 回源这一段的明文问题经常被忽略。用户到 CDN 是 HTTPS，但 CDN 到源站可能走的是 HTTP。Cloudflare 的 Full (Strict) 模式要求源站也有有效证书，Flexible 模式则是 CDN 到源站明文，这个区别很大。

检测和监控

用 `testssl.sh` 扫一遍自己的域名，看看支持的协议版本、加密套件、证书链有没有问题。Qualys SSL Labs 的在线测试也能给出详细报告。浏览器端在 Console 里看有没有 Mixed Content 警告，Chrome 的 Security 面板会列出所有非 HTTPS 请求。

服务端日志里筛选一下有没有 HTTP 的请求进来。如果 HSTS 生效了，正常情况不应该再有 HTTP 请求到达应用层。有的话说明要么 HSTS 没覆盖到子域名，要么有客户端在忽略 HSTS。

说到底，明文传输不是某一个环节的问题，是整条链路上任何一段没加密都算。HTTPS 是底线，HSTS 堵住跳转窗口，Cookie 标志防止泄露，应用层加密兜底。每一层单独看都不复杂，组合起来才能把口子收紧。

(责任编辑：百科)