RFC 3093：放行 HTTP 不等于批准内层数据包

摘要

RFC 3093 的 FEP 把完整 IP 数据报放在 HTTP 正文里，由防火墙内的一台协作主机解码，再注入自己的协议栈。
HTTP 连接通过，只能证明外层载体被放行；它不证明内层地址、端口、应用、用户、注入动作或最终结果符合策略。

防火墙认得的是信封

这份文档从一个当时已经清晰的冲突出发。互联网的端到端结构让主机可以试验新应用，而企业防火墙在路径中增加了一个决策者。应用即使在两端都能运行，只要流量不属于既有规则，就可能无法相遇。

RFC 3093 把一种回应推向了讽刺的极端：既然 HTTP 通常能穿过防火墙，其他流量就穿上 HTTP 的外衣。外部主机把 TCP/IP 数据报交给 FEP，FEP 将它编码成 HTTP 消息，经普通 Web 通路送到内部主机；内部软件解码后重建数据报，送进受保护主机的 IP 协议栈，仿佛防火墙不存在。

这条路径也把证据边界画得很清楚。防火墙观察并接受的是外层会话。内层数据包仍有自己的源地址、目的地址、传输字段和应用意义。对载体作出的决定，不会自然继承到货物。

内部协作者成为新的控制点

文档声称，这一方案没有破坏防火墙的安全模型，因为它必须得到内网主机配合；它又假设防火墙防范外部威胁而忽略内部威胁。这是 RFC 的论证前提，不是可以沿用的安全保证。能够解封并注入任意数据报的进程，本身正握有新的权力。

防火墙运营者控制外层连接是否通过；内部主机运营者决定是否运行 FEP、是否允许它写入协议栈；用户或应用决定要承载什么；隧道实现决定如何解析和重建。任何一个单独事实，都不能证明组织批准了它们组合后的行为。

因此，“HTTP 已接受”的日志不是内层流量日志。隧道端点收到消息，不等于已经注入；注入成功，不等于某个套接字收下；套接字收下，也不等于应用完成处理或外部结果发生。

可读字段只是重复副本

完整 IP 数据报保存在 HTTP 正文中。FEP 还把 TCP 字段以及可选的 IP 字段复制成新的可读 HTTP 首部：端口写成十进制字符串，大小写表达紧急性，生存时间写成句子，表面源地址还能改写成域名。

RFC 3093 自己说明，这些首部严格说只为便于阅读，因为正文已经携带完整数据报。这使它们不能成为独立权威。看见一个 TCP_Dport 字符串，不能证明正文中的目标端口，也不能证明它已认证或获准。两份表示可能冲突；实现必须明确哪一份控制重建，并在注入前完成校验和策略判断。

每个包又可以表现成 GET 请求或 GET 响应，以适应检查 HTTP 命令的防火墙。这并没有把内层数据变成普通网页请求。HTTP 是中间设备能够识别的表面形式。越是只检查熟悉外观，越能显出“识别协议”和“识别意图”不是同一件事。

玩笑保存了一个真实的策略故障

发布日期、故意滑稽的字段以及“没有真正安全考虑”的章节，都说明这是一份 Informational 挑衅文本，而不是安全部署手册。无需猜测作者的未写明动机，页面上的机制已经足够：只要端点愿意封装，粗粒度允许规则就可能变成通用运输通道。

RFC 2775 讨论透明度消失；RFC 2979 讨论防火墙行为和可配置策略；RFC 2663、RFC 3027 与 RFC 3234 描述 NAT 和其他中间设备的影响。SOCKS5 则要求应用与网关明确协商，并可选择认证方法。这些材料帮助区分层次，却不能证明 FEP 曾被实现或部署。

持久的结论不是“防火墙无用”，也不是“隧道必胜”。规则可以准确放行 HTTP，同时对藏在其中的语义保持沉默。要证明策略真正执行，必须辨认并记录隧道端点身份、允许的内层协议和目的地、注入权限、应用接收与可观察结果。外层一个绿色事件不能替代整条证据链。

防火墙放行了 HTTP，却没有批准藏在里面的包：RFC 3093

为何重要

摘要

防火墙认得的是信封

内部协作者成为新的控制点

可读字段只是重复副本

玩笑保存了一个真实的策略故障

来源

档案背景详情

Strategic Circle

Leadership Alliance

Strategic Circle 专属简报

Leadership Alliance 简报