行业情报
最新文章
关于基础设施运营商、政策决策、市场动向与数字权力转移的最新情报。
案例档案
TXT 记录完全正确，供应商仍不等于域名所有者：ACME DNS-01 与委托验证的权限边界
供应商的员工账号、CI 密钥和证书库权限都已撤销，`_acme-challenge` 却仍委托到它管理的验证区。供应商用尚存的 ACME 账户申请通配符证书，正确的 TXT 摘要随即出现，验证全部通过。协议没有出错；漏项发生在只画到应用层的离场清单里。
案例档案
边界不是过滤器：BGP 最大前缀数如何把容量预算变成断会话权限
多一条路由，为什么可能导致此前已经正常承载流量的整组路由一起撤走？答案不在那条新路由是否“有问题”，而在最大前缀数策略把计数结果绑定了什么动作。只有把计数口径、保护对象、合理余量、执行后果和转发证据写清楚，这个看似简单的上限才是一项可治理的网络控制。
互联网历史
那封无法说出哪个包已到达的回执：Karn 算法如何教 TCP 拒绝一次测量
同一段 TCP 序列空间先后发出两次：第一次是原始发送，第二次发生在计时器到期之后。随后只有一个 ACK 把确认边界向前推进。它足以证明接收端已经越过那些字节，却没有说明究竟是哪一次发送促成了确认。Karn 算法把这个缺失的因果标签变成一条运行纪律：宁可暂时没有新的往返时间，也不能让无法归因的样本改写 TCP 的时钟。
案例档案
DNS 回答安全，不等于主机选择正确：SSHFP 指纹的权限边界
运维人员输入 `ssh db`。网络下发的搜索后缀把短名补成了另一个完整域名；该名称的 SSHFP 通过 DNSSEC Secure 验证，服务器给出的主机密钥也与指纹完全一致。所有密码学证明都成立——只是成立于客户端选中的主机，而非操作者心中那台数据库。
案例档案
签名通过了，From 地址却不是签名者：DKIM 域签名的权力边界
邮件把 `bank.example` 显示为 From 域，DKIM 结果为 pass；真正完成签名的却是攻击者控制的 `receipt-alert.example`。密码学没有出错，系统只是把一个域的证明送给了另一个域。
案例档案
摘要完全吻合，发送者仍然未知：HTTP `Content-Digest` 与校验和的权力边界
那份策略文件没有在传输途中损坏。它从一开始就是恶意内容，而且附带了计算完全正确的 `Content-Digest`。服务显示“已验证”，随即执行文件。攻击者没有破解哈希算法；他只是同时选择了正文和摘要。
互联网历史
沉默猜错的掩码：ICMP 如何替一台新主机辨认子网
一台主机醒来时已经拥有 IPv4 地址，却不知道哪些目的地就在同一根线上。它广播询问子网掩码，没有任何回应。旧规范允许它先采用地址类别对应的“未划分子网”掩码，但同时承认：这个猜测可能是错的，因为负责回答的 agent 也许只是暂时宕机。等经明确授权的 agent 恢复，它会用一枚未经请求的广播纠正全网。这个几乎被遗忘的启动机制留下了一条清楚边界：沉默最多支持可逆的运行选择，发布配置的权威却必须另有来源。
案例档案
请求头写着“客户端”，但对端地址并不认同：HTTP `Forwarded` 与代理链的授权边界
一台源站按设计只应接收两层反向代理转来的请求，却仍可从公网直达。攻击者直接连上源站，把管理员白名单地址放进 `X-Forwarded-For` 最左端，IP 规则随即放行。解析器没有读错字符；真正的错误，是让一个未经授权的网络对端替更早的节点作证。
案例档案
名字选中了 TLS 上下文，却没有授权请求：SNI 路由提示的权威边界
一台多租户网关收到 `tenant-a.example`，准确选中了租户 A 的证书与 TLS 配置。随后它又把这次选择记成“租户 A 已认证”，让没有任何客户端凭证的连接靠近管理接口。密码学没有失败；失败的是系统把客户端自己填入的名字升格成了客户端身份。
互联网历史
防火墙不能随意擦掉的标签：IPv4 安全选项在封闭网络中的余生
一台防火墙看到陌生的“安全选项”，便把它从 IPv4 首部中剥掉。数据包表面上更干净，却未必更安全。在依靠敏感度标签的网络里，接收端可能拒绝这枚无标签数据包，也可能依据入口接口补上一个过高或过低的隐含标签。类型 130 的特殊之处不在于公网上到处传递机密信息，而在于同一台商用设备既可能处于开放互联网，也可能处于封闭的多级安全系统；设备仅凭选项存在，无法预知自己所在的制度环境。
案例档案
证书签名通过了，握手却没有完成：TLS 1.3 `Finished` 的转录权威
监控平台在服务端 CertificateVerify 验签成功时就记下一次“安全握手”。下一条加密握手消息的 `Finished` 校验失败，客户端按规范发送致命错误并断开。证书私钥确实完成了它应有的证明，系统却提前替它宣布了另一项尚未发生的事实。
互联网历史
证明回程存在的令牌：DNS Cookies 为何不是身份凭证
EDNS 中一个很小的选项，改变了 DNS 服务器理解 UDP 源地址的方式。它不能说明请求者是谁，却能说明一件更窄、也更实用的事：先前发往这个表面地址的响应，曾被某个端点收到；如今，对方带回了服务器签发的令牌。
IETF
报文尚未丢失，拥塞已经留下标记：ECN 的漫长机制史
互联网曾长期用丢包来证明拥塞：先让传输受损，再由发送端从损失中推断路径承压。显式拥塞通知（ECN）把关键时点向前挪了一步——路由器可以在报文仍然完整时留下证据；但这两个比特只有在队列、接收端、隧道和发送端共同守约时才有意义。
互联网历史
以沉默表示成功的测试：Discard 协议究竟能证明什么
测试者向 9 端口发出一段已知字节，远端没有回话。这里不能立刻写“超时”，也不能写“接收成功”。RFC 863 对 Discard 的规定正是收到数据、将其丢弃、不发送应用层响应。空白是合规行为，却不是收据；要判断测试结果，必须先说清观察来自本机、传输层、远端进程，还是另一处独立测量点。
案例档案
边缘节点协商了 HTTP/2，源站却仍说 HTTP/1.1：TLS ALPN 只拥有一条连接的协议决定权
浏览器提出 `h2` 与 `http/1.1`，边缘节点选择 `h2`，握手完成，HTTP/2 帧也正常流动。监控随后把源站标成“原生支持 HTTP/2”。这个结论越界了：边缘节点已经终止第一条 TLS 连接，又以独立客户端身份向源站建立第二条连接，并在那一段使用 HTTP/1.1。ALPN 证据没有错，错的是把它跨过终止点继续使用。
互联网历史
没有语法的时钟回答：Daytime 为什么只保证人能看懂
客户端连上 13 端口，收到一行清楚的日期，连接也正常结束。换一台服务器，同一时刻却可能换一种字段顺序、年份宽度和时区写法。两次通信都成功，因为 RFC 867 规定的是“给人看的时间回答”，从未承诺一种可由程序通用解析的日期语法。
案例档案
CA 名称在清单里，身份却未获准：TLS `certificate_authorities` 的选择提示权边界
客户端看到服务器列出的 CA 名称，挑出一张匹配的证书；服务器也确实把证书链验证到了受信任锚点。随后，业务服务拒绝了这个主体——它不属于目标租户，也没有所请求操作的角色。这里没有密码学矛盾。故障发生在观察系统把“被选中”“已验证”和“可执行”压成同一个绿色结论之时。
案例档案
签名是真的，状态仍可能滞后：TLS OCSP 装订与缓存答案的权限边界
证书在 10:07 被撤销。10:11，服务器仍向新连接附上了一份签名完全正确的 `good` 响应，`nextUpdate` 还有数小时才到。这里没有伪造：答案是真的、仍在声明的时间区间内，却已经落后于现实。真正误导人的，是监控把这三件事压成了一个绿色字段：`revocation_checked=true`。
互联网历史
一问一答为何永不停下：Echo 与 Chargen 怎样拼成网络回路
一只数据报从端口 19 发出，绕到端口 7，又原样回到端口 19。起点已经沉默，数据包却仍在两个服务之间往返。每一端都只做一次合规回答；问题在于，一端的回答恰好成了另一端的新问题。
案例档案
套接字关了，交易没有结束：TLS `close_notify` 的终止权限
客户端收到了“成功”，服务器也完成了看似正常的 TLS 关闭。几毫秒后，数据库却拒绝了那次写入。这里没有密码学矛盾：`close_notify` 只证明服务器在一个 TLS 发送方向上不再发送消息，不能证明付款、授权或状态变更已经持久化。真正的故障，是系统把连接终止当成了业务结论。