unencrypted connection漏洞

打开浏览器开发者工具，切到Network面板，刷新页面。如果某个请求的协议列写着"http"而不是"https"，那这个连接就是未加密的。任何人——同一个咖啡馆里的陌生人、你楼上的邻居、路径上任何一个路由节点——都能看到你传了什么。

这不是什么高深的安全知识。HTTP协议从1991年诞生起就是明文传输，请求头和响应体全部裸露。1994年网景搞出了HTTPS，用TLS层把数据包起来。三十年后，还有大量网站在用裸HTTP跑关键业务。

一个真实的抓包场景

去年帮朋友排查他公司内网的问题。他们有个后台管理系统，员工登录用的账号密码走的是HTTP POST请求。我在他电脑上装了Wireshark，随手抓了几秒包，过滤出HTTP流，右键Follow TCP Stream——用户名和密码就躺在那里，明文，连Base64编码都没有。

他当时表情挺精彩的。

更离谱的是，这个系统只在内网用——他们一直拿这个当理由。可内网不等于安全。ARP欺骗、交换机端口镜像、Wi-Fi蹭网，随便哪个入口都能截到这些包。

为什么这种事还在发生

成本问题。HTTPS需要证书，需要配置，需要处理证书过期。对小团队来说，HTTP能跑就行。有些老系统从十年前上线就没动过，代码里写死了http://的接口地址，改起来牵一发动全身。

还有个常见误区：很多人觉得"我们没什么值得偷的"。但攻击者要的不是你的数据本身，而是会话令牌。拿到Cookie就能冒充你的身份登录，看你所有东西，用你的权限操作。你的数据值不值钱不重要，你的身份值钱。

公共Wi-Fi是最典型的猎场。机场、酒店、咖啡厅，攻击者架一个同名热点，你连上去之后所有HTTP流量都从他手里过。甚至不需要什么高级工具，sslstrip这类工具能把HTTPS降级成HTTP，用户端完全无感。

检测和修复没那么复杂

浏览器地址栏是最直观的检测点。Chrome从68版开始对所有HTTP页面标注"不安全"，这个提示到现在还有人不当回事。

修复路径也很清晰：

Let's Encrypt提供免费证书，certbot工具能自动配置续期。Nginx加几行配置就能把HTTP 301重定向到HTTPS。HSTS响应头告诉浏览器"以后这个域名只用HTTPS访问"，彻底堵死降级攻击的路。这些操作一个下午就能搞定。

真正难的是那些嵌在代码深处的硬编码HTTP地址。我见过一个项目，前端调后端API用的是http://，因为后端没配证书。问为什么没配，答曰"运维说证书要花钱"。一个通配符证书一年几百块，比一次数据泄露的善后成本低太多了。

混合内容：容易被忽略的角落

页面本身是HTTPS，但里面加载了一张HTTP的图片、一段HTTP的脚本。浏览器会警告"部分内容不安全"，但很多人直接忽略。问题在于，那个HTTP脚本可以读取整个页面的DOM，包括你在HTTPS表单里输入的内容。加密的壳被一个明文脚本捅穿了。

Chrome现在默认阻止混合内容中的脚本加载，但图片和媒体资源仍然会放行。检查方法很简单：开发者工具的Console面板会列出所有混合内容警告，Security面板能看到更详细的连接状态。

说到底，未加密连接的问题不是技术难题，是意识和习惯问题。工具都现成的，配置文档一搜就有。拖着的理由无非是"现在能用"和"以后再说"。但数据在网络上跑的时候，不会等你准备好。

很赞哦!（44554）